Crunch Time For Army Missile Defense Network, IBCS

WASHINGTON: Northrop Grumman‘s IBCS network could revolutionize how the Army does air and missile defense, if they can get the software to stop crashing. Since Pentagon testers found in February 2016 that the system had to abort, on average, every six to eight hours, the program has worked hard to make the software “more robust,” said Northrop manager Rob Jassey.

Now, “we are ready to have a full-up Soldier Check-Out Event (SCOE) that they can look at the tremendous improvement in reliability,” Jassey told me confidently. “The user interface has been completely (redone).” That test will come late summer and early fall, in time to influence the critical “Milestone C” decision to start production, originally scheduled for November ’16 but now expected this year.

The software is so hard because IBCS is extremely complex. (Even the name is a nested acronym for IAMD Battle Command System, IAMD meaning Integrated Air and Missile Defense). It’s meant to replace seven separate command-and-control systems used by today’s Army with a new paradigm for air and missile defense. Instead of each weapons system requiring its own dedicated radar and command posts — e.g. a Patriot radar feeds data to a Patriot command post, which gives orders to a Patriot launcher — IBCS is designed to draw data from every sensor, fuse the disparate information into a single picture that’s more than the sum of its parts, and provide targets to any launcher.

The network will even include radars that weren’t designed to provide sufficiently precise data for the system’s targeting, most notably the Sentinel early-warning radar. That adds “hundreds” of new sensors, said Jassey. The hard part is that also requires upgrading all those hundreds of additional sensors to report data they originally didn’t.

In fact, every system currently in Army service requires some kind upgrade before it can talk to IBCS. Physically, it’s not a big deal. “In the Sentinel, it turns out to be just a card that slips into the (existing) computer rack,” he said; on some systems, “it’s a little box sitting on the launcher that hosts the card.” But it requires writing — and testing, and rewriting — software for a host of different systems by a host of different manufacturers. (Future Army systems will be IBCS-compliant from the start, as might even some Air Force or Navy ones).

“This is not child’s play,” Jassey acknowledged. “The government, as the lead system integrator, is doing yeoman’s work to bring together an enterprise like that.”

Because the government, not Northrop or some other contractor, is the lead integrator, “the government owns the entire architecture. There’s not a proprietary stitch in it,” Jassey said. “A lot of people didn’t believe we could do fire control using an open systems approach…. We spent a good chunk of change building a prototype tactical operations center (to) prove the basic constructs.”

Once IBCS is in place, however, the government-owned open architecture makes it easier to upgrade any component, without having to go back to the original manufacturer of proprietary systems. What’s more, the Army won’t need to buy a complete set of sensor, shooter, and command post every time it wants a new capability. Instead, it can just buy a new radar or a new weapon as desired and plug it into IBCS. The Indirect Fire Protection Capability (IFPC) program, for example, is basically just developing a missile launcher that will rely on IBCS for command-and-control and for targeting data.

As a retired Army air defender himself, Jassey says this model will reduce redundant spending. “When I wore a green suit, what I wanted was to stop spending so much money on command and control systems that were not talking to each other,” he said. The Army also won’t have to train troops to operate multiple different command-and-control systems: Once you’ve learned IBCS, you can use it with anything.

Of course, IBCS has to work first. Simulations and laboratory tests can only go partway in testing such complexity, Jassey said, which is why field tests in realistic conditions with real soldiers are vital. “We’ve had soldiers on it, hammering on it,” he said. “We’ve been running long-duration runs both here and in the government system integration lab, (and) by long duration I mean covering days, to make sure the software stays running solid.”

Contrast that “days” to the frequent failures reported last year by the Director of Operational Test & Evaluation‘s annual (DOT&E) report: “(IBCS) demonstrated poor system reliability, with 6 to 8 hours of Mean Time Between System Abort (MTBSA) compared to the (Army) entrance criteria of 31 hours MTBSA. (It) demonstrated a 6 percent likelihood that it could operate for 72 hours without experiencing a failure that would result in system abort. The warfighter requirement is a 90 percent likelihood…. The EOC (Engagement Operations Center) demonstrated an average operating time of up to 16 hours without a failure that results in ineffective operations; this is significant when compared to the minimum requirement to operate for up to 446 hours.”

Those figures come from the February 2016 Limited User Test (LUT), said Jassey, the first time IBCS in all its complexity was employed in field conditions. “That was the first time anyone had seen it all together,” he said. They learned a lot from the LUT, he said, and “the improvements are enormous,” Jassey said. Now IBCS is ready for a Soldier Check-Out Event — testing the software, but not firing live weapons — set to start sometime late this summer, he told me: “We’re waiting with bated breath.”