Army-canceled Ground Mobile Radio costs $ 6 billion to fail.
In 1997, the Department of Defense began striving for the perfect family of radio stations: software-defined radio stations that, like computers, could be reprogrammed for various missions and communicate with everything the US military uses. Digital signal processing can adaptively use available radio spectrum based on current needs, turning troops, tanks, aircraft and ships into broadband radio-based network nodes.
The aim was to solve radio problems such as the one in Afghanistan, described in detail by Center for Public Integrity in January 2012, soldiers watching an ambush on a nearby ridge found themselves constrained by the extremely volatile needs of their many radio systems:
They had short-range models to talk to the recovery team; longer-range versions to reach headquarters 25 miles away; and a backup satellite radio in case the mountains block the transmission. An Air Force controller carried his own radio for conversations with jet fighters overhead and a separate radio for downloading streaming video from the plane. Some of these radios only worked while the soldiers were stationary; others were simply too cumbersome to work on the go.
But the program designed to fix the mess, called the Joint Tactical Radio System (JTRS), has instead become a massive mess of its own software and hardware development in 15 years, including five subroutines and multiple multibillion-dollar contracts. It was a financial disaster for DOD. Billions have been thrown away by technology that will never see the light of day, despite numerous heroic efforts to pull the project from the brink of disaster.
JTRS provides a textbook for the case of what no to do in a technology development program, proving that even a few great ideas can’t save a project that has been over-concretized and under-tested and that keeps flashing about what’s going on in the world around it.
Pyrrhic victory
In May 2012 Executive office of the JTRS joint program, the DOD office that runs JTRS, announced what should be the crowning achievement of the 15-year program: hardware certification. Land Mobile Radio (GMR), one of the main sub-programs of JTRS and the first radio to use the new military standard for broadband network waveform (WNW), was certified for use by the National Security Agency.
“This achievement enables the Ministry of Defense to use years of investment and technological progress related to the development of GMR,” said a spokesman for the Executive Service of the JTRS Joint Program. Read also : Germany joins European Secure Software Defined Radio ESSOR.
The GMR forms the cornerstone of the Army’s plan to build mobile ad hoc networks that connect troops in the field, as well as Army and Air Force planes flying in support and commanders back to operations centers. With WNW as the backbone of the network, Soldier Radio Waveform for communication with handheld and other mobile radios, and waveforms for satellite and terrestrial communications, GMR will be the Internet router on the battlefield. And now he was ready to go.
Well, something like. After burning more than $ 6 billion to develop GMR alone, the military actually canceled the project back in October 2011 after the army failed. Network integrated environment (NIE) testing. Big, bloated and complicated, GMR couldn’t handle the heat of White Sands, New Mexico, and turned out to be less of an iPhone than a mainframe in terms of complexity.
IN Article from July 2012 in the National Review Review, Lt. Col. Dan Ward, an acquisition officer stationed in Afghanistan, openly explained GMR’s shortcomings:
The NIE exercise highlighted the unpleasant fact that soldiers sometimes have to send critical messages during battle. Very impatient, they may not be very excited to wait 10 minutes for the radio to go through a slow series of charging processes … If someone made a TV commercial for GMR, it would undoubtedly include a replica of the wait. Except in battle, sometimes you really have no patience. It is a pity that GMR had to go to war, because it would obviously be a pretty sweet system in an environment where the temperature and pace of work are low.
So, although GMR is “certified for use,” the military doesn’t really want to use it. And the system is not made, costing state money. While the military waited years for GMR, it spent $ 11 billion more on “legacy” radio stations based on Cold War technology. As Ward pointed out, the military can still pay billions more to get the radio stations it actually needs – just as the war in Afghanistan is ending.
GMR, broken down into schematic form. Who wouldn’t want to spur this around the battlefield?
Department of Defense
Open source radio
Basically, JTRS is built on what sounds like a good idea: separating radio standards from transmission hardware by creating an open “operating system” common to all military radio stations. If radio waveforms were defined in software rather than hardware, they could be moved as applications from one set of hardware to another or upgraded with a simple software update.
Taking a page from open source licensing schemes such as GNU, the basic software architecture, and “waveforms” – application-specific radio communication formats – was left to anyone building DOD radios, with the proviso that any code execution must be brought back to the JTRS code store. On the same subject : Rafael demonstrates Transparent Battlefield capabilities for German Army – Digital Battlespace. Success was, if success can be measured by the number of contributions: this repository now contains four million lines of code.
The core of JTRS is Software communications architecture, a framework for applications for radio stations built on Common Site Request Broker Architecture (CORBA) and a POSIX-based real-time operating system. (SCA was able to find life outside of DOD in an open source implementation that runs on Windows and Linux called OSSIE.)
The idea of the open architecture was to ensure that all communication facilities that each of the purchased services of DOD will work smoothly. And because core software and waveforms will be freely available to anyone – even companies that have not joined major JTRS programs – the total cost of getting new radios must be drastically reduced, allowing competition between manufacturers based on a well-defined standard. In other words, JTRS had to compromise the software-defined radio market.
When I spoke with the then executive director of the JTRS program, Denis Bauman as early as 2008, he said, the open source database allowed JTRS to “sign up” new providers on an ongoing basis. Although there was still an open competition for the design phase of each component radio program, production would always have more than one option. “We require to qualify at least two sources,” Bauman said; these qualified suppliers will compete annually for the production of radio stations in batches.
The Harris Falcon III handles a “JTRS-compliant” radio developed independently by Harris with access to the JTRS code store.
Harris Corp.
This approach has paid off, at least with some of the first transitional radios that could interact with the wider JTRS program. For example, in 2007, Thales won the contract for the Consolidated Intermediate Single-Channel Handheld Radio (CISCHR), a project merged into JTRS by the US Special Operations Command. But Harris developed his own version of his Falcon III radio, which was “JTRS compliant” and could use Soldier Radio Waveform, as well as other inherited radio formats that were ported to the architecture using the common JTRS repository. Harris sold over 100,000 “JTRS compliant” radio stations for the army and marines in open competition with the “official” Thales radio; competition between the two for JTRS business saved the military $ 104 million for the first batch of 39,000 radio stations alone.
If JTRS has just been a software standards effort focused on waveforms, this could be an article about the “genius of JTRS.” Unfortunately it was not. And this is not the case. The various services, especially the military, are not content with companies competing on a software standard. They increasingly wanted more hardware features.
Some of the most fundamental problems with JTRS (and especially with the GMR sub-program) are common to any large, unsuccessful technology project – only on a larger scale. The scope of JTRS was so huge from day one that there was no manipulation The “iron triangle” of project management can keep costs and schedule under control.
Inadequate understanding
Military technology often pushes the edge of what is feasible – that’s why agencies like it DARPA exist. But when JTRS was originally conceived in 1997, the Army’s most significant previous work on software-defined radio was an army project called SpeakEasy– the first version of which occupies the entire rear of a military truck. Clearly, an ambitious project like JTRS has had a lot of basic research to prepare before it can deliver something useful. Looking back, the military greatly underestimated the challenges ahead.
“Ultimately, building a radio that works with all the different waveforms envisaged by the project required some basic physical rules to be imposed. Read also : More Bandwidth for Software Developers Means Better Apps for SIGINT/ISR/Comms « Breaking Defense.”
IN letter, letter sent to the chairman of the House Armed Services Committee in October 2011, explaining the cancellation of the GMR program, acting Deputy Secretary of Defense for Acquisition, Technology and Logistics Frank Kendall wrote that “the technical challenges of mobile ad hoc networks and scalability they are not good of course due to the immaturity of the technology ”when the program started.
First and foremost was the problem with software development. When JTRS started, software-defined radio (SDR) was still in its infancy. The project’s SCA architecture allows software to manipulate field-programmable port arrays (FPGAs) in radio hardware to reconfigure how its electronics work, exposing these FPGAs as CORBA objects. But when development began, CORBA’s hardware implementations for the FPGA did not exist in any standard form.
Moving waveform code from one set of radio hardware to another didn’t just mean recompiling – it often meant significant rewriting to become compatible with any FPGA used in the target radio, followed by additional tweaking to make it acceptable. level of productivity. The result: the challenge of the main development tasks for each of the initial projects was often grossly underestimated. Some of these issues have been addressed by specialized CORBA middleware, such as OpenFusion by PrismTechbut software tools have been around for a long time.
Then there was a set of requirements required by the waveforms themselves. Each waveform requires different frequencies; while radio electronics can be software configured for those significantly different frequencies require different antenna properties and modifications to the radio hardware itself. Ultimately, the construction of a radio that worked with all the different waveforms envisaged by the project required some basic physical rules to be distorted.
Having an unspecified technical problem is bad enough, but it gets even worse when a serious “creep of scope” occurs during a 15-year project.
Comments are closed.