WASHINGTON — Pentagon procurement has plenty of problems, but two of the biggest are acquiring modern software program 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 Also Manned Battling Vehicle , a program whose success depend s not on armor or guns, b ut 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 simpler “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 Military leaders are considering a separate series of contracts specifically for software development, in parallel to the contracts already planned for the physical ve hicle. 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 system manager for Maneuver Combat Systems, oversees OMFV. And if the Armed service can decouple the pace of software improvements from the much slower cycle for new hardware, Jurand informed Breaking Protection, “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 almost all software advancement as part of the current five-phase OMFV program or even spin a few off as a separate set of contracts.
OMFV Could Follow Robotic Vehicle Program’s Footsteps
Another Military services program, the Robotic Fight Vehicle (RCV), is pioneering the two-track approach with separate agreements focused on hardware and software — though it’s still too early to say how successful it’ll be . RCV contracted along with QinetiQ and Textron to build experimental remote-controlled mini-tanks, including the embedded software program to run the particular vehicles. But it’s also contracted, through the Defense Innovation Unit, together with Applied Intuition for application development tools and with Kodiak, which makes self-driving trucks, for navigation algorithms.
“It’s new ground for the department, ” said Lt. Lacet. Chris Orlowski, Dean’s product manager with regard to Robotic Overcome Vehicles. “I’m not aware of any other programs that have structured a hardware and software program in seite an seite like this. ”
“This is something that’s going to be a challenge for us” in the RCV program, Orlowski said. “We cannot completely decouple this hardware and the software. ”
For instance, he said, specific physical components such as sensors may require very specific computer 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 certainly let the Navy pick the “best of breed” companies regarding software growth, a highly specialized skillset, rather than just award everything in one bundle to the best builder associated with hardware.
Ultimately, Orlowski added, the RCV program might split things up further, awarding contracts to get specific program functions. “We’re not ready to make a decision [yet] on how to compete software at the module level, ” this individual said. “We’re monitoring different vendor approaches. ”
To have companies contend for individual modules, however , you need your software package to be made up of modules in the first place. Modularity, in turn, requires a common set of requirements for how those various pieces of software programs plug-and-play together — a Modular Open Systems Architecture like the Army’s GCIA. Even when a specific make and model of sensor, say the LIDAR, requires unique applications to run, Orlowski said, “the interface to those sensors is then standardized with the GCIA interface, [so] often the LIDAR [data] is discussed. ”
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, plus bridges. In the 21 st century, the standards armored vehicles have to meet are increasingly electronic. That’s why the Army’s PEO-GCS has developed what it calls the G CS Common Facilities Architecture , GCIA. GCIA, consequently, builds upon existing specifications, said PEO-GCS Dean, particularly the military aviation community’s FACE ( Future Airborne Capability Environment ), albeit customized for floor vehicles.
GCIA is a living, evolving thing, not a static template, in addition to it’s being developed in concert with industry. Currently, said Dean, “we’re about GCIA version 2 . 0, ” which is currently circulating for comment.
All OMFV proposals must be designed from the ground up to meet GCIA criteria, while RCV is working towards compliance. Dean furthermore hopes to gradually upgrade existing armored vehicles like the 8×8 Stryker to use GCIA-compatible parts, allowing them to share at least several parts and even programs across the fleet, like collision detectors or navigation algorithms.
Yet it’s impractical to rip out all the existing elements that do not really meet the standard. The reason: There’s been a new radical revolution in exactly how hardware and software work together.
During the Cold War, when processing power was minuscule by modern expectations, a given piece of hardware, such as a gunsight, might require only a few lines of program code, painstakingly tailored to run on the specific circuitry that could be crammed in that component. You couldn’t upgrade the equipment without rewriting the computer code (and vice versa). Any exchange of data between diverse components — say the gunsight and a targeting computer — was laboriously custom-built together with hardwired. Update one component, and you had to carefully retest the whole automobile 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 components can host its own miniaturized computer operating complicated applications, those devices can discuss lots of data at high speed over a network (wired or perhaps wireless), and additionally modern plans rarely care what particular make and model regarding computer they’re running in thanks to programing techniques known as containerization not to mention virtual machines. So you can replace one component of software or maybe hardware without having to modify and also re-test every thing it’s connected to — as long as everything is built to a common regular that lets it share information.
Traditionally, stated OMFV plan manager Jurand, programs needed to bundle a bunch of upgrades with each other into a single package for efficiencies of scale and test them all at once, a process known as “block upgrades” that will typically took multiple years. But with every OMFV element required to become GCIA-compliant, he or she said, you can push out individual enhancements — a new sensor, a better navigation algorithm, and so on — much more quickly. His objective is to update OMFV at least once a year “at a minimum, ” he mentioned, likening this to automakers rolling away their new models each fall.
The Global Upgrade Pipeline
That streamlined process could allow much faster fixes in order to new bugs discovered in the field, faster exploitation of new technology, and quicker countermeasures to be able to new threats, that is, if the Army can work out a way to swiftly as well as securely provide new signal to combat units around the globe. “That’s some sort of 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 car can switch to whatever programs works best for a given situation. For instance, you might use one navigation software while on the road, then in order to another app, perhaps coded by a different company altogether, when you go cross-country. Or maybe even have specific methods optimized pertaining to specific terrains, like desert, swamp, as well as forest. Likewise, you might use one target-recognition AI meant for enemy storage containers, another designed for infantry. Or perhaps use 1 targeting AI by night and one simply by day, or one focused on 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 greatest where.
“It is very hard, technically, to make … one formula to rule them all, ” Jurand explained, “because certain algorithmic techniques will perform better in certain environments. ” So it might be best to possess multiple segments for any given function and swap between them.
“You’ve got to have sufficient processor space … to house two distinct two several software solutions to the same problem set, ” Jurand acknowledged. “But that is not an uncommon thing” nowadays.
Engineers have always aimed to style new automobiles with more horsepower and stronger chassis compared to strictly needed, to allow a good margin just for growth, Leader said. That’s why your Bradley has been able to accommodate so many pounds of updates over the last four decades. In the future, he claimed, you’ll also need extra computing power.
“Future capabilities growth is largely going to be about how we handle info, ” says Dean reported. “We’re starting to see how . collecting plus analyzing files, integrating of which data, and then turning the fact that data into information [from] which you generate combat capability is all will be based really heavily with software. ”
“Today, our mechanism for the purpose of handling records on a platform is mostly the brain of the motor vehicle commander. He has a bunch of receptors which are feeding him information, ” Dean continued. “I’m looking through a scope in addition to 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, Leader 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.