| Submit your comments on this article |
| Home Front: Tech |
| Army Communications Systems' Problems |
| 2005-05-01 |
| The Army's massive modernization project, Future Combat Systems, isn't just one program. It's hundreds of interlocking, interwoven efforts to update armor, uniforms, logistics, medical care, and much, much more. A few key threads hold the whole tapestry together. And one of them is rapidly coming undone. Without communications -- specifically, without the Joint Tactical Radio System, or "Jitters" -- many of FCS' most innovative efforts just won't work. FCS is an attempt to turn the Army into a force that takes out opponents with ultra-precise attacks and almost Godlike knowledge of the battlefield instead of with overwhelming firepower. To make this nimbly lethal dream come true, the Army needs almost-instant information-sharing, both between soldiers and with FCS' new fleet of robots. It needs Jitters. Right now, the Army isn't getting what it needs. Jitters is flailing, badly. As we noted the other day, the Army has put one of the program's main contractors, Boeing, on notice that it could cancel one component, or "cluster," of Jitters in a month. Winds of Change offers today some stellar background on the program -- what Jitters does, the problems it faces, and what might happen next. And it the site's comments section, a Jitters engineer weighs in on how the program got so tangled up. Good stuff. THERE'S MORE: Meanwhile, Inside Defense reports, the Army is starting to look around for alternatives to Jitters. The Army's next-gen set of rockets is called the Non-Line of Sight Launch System (NLOS-LS). It's supposed to rely on Jitters' "Cluster Five" to direct its assaults. But, like Boeing's component of the radio system, Cluster Five "has hit its own program snags," says Inside Defense. As a result, the Army is considering the possible use of surrogate systems. NLOS-LS is made up of three key components: the Precision Attack Munition, a direct-attack missile that can autonomously acquire a target; the Loitering Attack Munition, which is being designed to fly to a target up to 70 km away and loiter above it for up to 30 minutes before striking; and the Container Launch Unit, the box that stores, commands and fires the missiles. The CLU, which officials call "the heart and soul of the program" because it contains the... information that... will tell the PAM where to go, depends on [Jitters]. "The number one risk to the NLOS-LS program currently is the network," said Ric Magness, president of NetFires LLC, a joint venture between Lockheed Martin and Raytheon established to build NLOS-LS. NLOS-LS is supposed to rely on a future software programmable radio called the Joint Tactical Radio System's Cluster Five, but that program has hit its own program snags. As a result, the Army is considering the possible use of a surrogate for the PAM and the CLU. According to a Government Accountability Office report, JTRS -- designed to transmit voice, video and data -- was put on a system development and demonstration path with immature technologies and few well-defined requirements. The program faces technical challenges because of its size, weight, power and data processing requirements. Its early development was delayed because of a contracting dispute. "Consequently," the report said, "the Cluster 5 radios are not likely to be available" for the initial roll-out of FCS." And that includes the new rocket system. AND MORE: Winds' sister site, Defense Industry Daily, is tracking the criminal investigation into the disfunctional search and rescue radios L-3 Communications has built for the Army. |
| Posted by:Anonymoose |
| #1 The problem with making such a complex, interwoven set of improvements simultaneously is that the probability of failure is multiplicative, not additive. Thus, if each part of the total project has only a 5% chance of failure, but there are twenty sub-projects, the total chance of success is really, really low (the exact answer I leave as an exercise for the reader.) I watched this happen on a product development project Mr. Wife worked on in the mid-80's -- they never did manage to make all the improvements dovetail into a manufacturable product, although they could make it by hand at seven times the maximum consumer-acceptable retail price. In the end, they were able to take a number of the sub-projects and work them into related projects, so the work wasn't lost, but they were never able to realize the dream. From a management perspective, one super-product would seem to be the most efficient way to go, but unfortunately reality tends to intrude most uncomfortably. I would suggest that the most important bits, eg battlefield-wide instant information sharing, be completed first, then serially develop the other things to fit with that key product. |
| Posted by: trailing wife 2005-05-01 10:46:10 PM |