MISSILE DEFENSE "GLITCH?" YEAH, RIGHT

FacebookXPinterestEmailEmailEmailShare

Everything is working perfectly. There is nothing -- repeat, nothing -- to worry about. The reason the missile defense system flunked it's most recent $100 million test? Just a "very minor" software glitch, insisted Missile Defense Agency chief Lt. Gen. "Trey" Obering. It was inconceivable, Obering told the Washington Post, that such a problem could ever, ever happen again. The Ground-based Midcourse Defense system may have face-planted this time. But against a real missile, he promised, it was absolutely sure to work right.

ift9f.jpgProviding the first detailed account of what went wrong, Obering told reporters that the countdown was automatically aborted when a routine system check of internal electronic signals detected a potential problem. The check showed that too many electronic messages had been missed in the signal flow between the flight computer and the unit that controls the interceptor's thrusters.
In retrospect, Obering said, designers of the interceptor had imposed too tight a limit on the number of allowable missed messages.
"It turns out we had overly constrained the system," he said.
Obering called the chances of such a glitch occurring "very rare." If it had happened during an actual crisis, with an enemy missile heading toward the United States, the system would have simply bypassed the faulty interceptor and launched another one, Obering said.

Sounds reasonable. But Philip Coyle, the former head of the Pentagon's office of Operational Test and Evaluation, isn't buying it.
First of all, Coyle noted, the tests that the anti-missiles keep flunking are way, way over-simplified. In the December trial, called Integrated Flight Test (IFT)-13C, the target was fixed with a radar beacon and GPS locator, making it pretty damn easy to spot.
More importantly, perhaps, is the fact that there's only one target. If Kim Jong Il is ever steamed enough to lob missiles at us, you can be sure he ain't gonna shoot them off one at a time.
Secondly, that "minor" glitch? It turns out that it's in a very major part of the missile defense system -- one that's had a whole bunch of problems in the past. Click here to continue on, as Coyle looks at just how significant the anti-missile system's problems really are.


For more background than you could possibly want, rumor has it that the failure in IFT-13C was in the CLE. CLE is short for Command Launch Equipment. It's a big computer system and part of the Ground-based Interceptor (GBI) Support System. Lots of software is in the CLE system, and they've had significant problems with that software. Part of the CLE is on the ground and part is in the interceptor.
It's built by Northrop Grumman, and, according to their website, "controls the interceptor through launch, providing near real-time trajectory planning, commanding, and health and status monitoring."
Northrup says, "The CLE software was developed on a highly accelerated schedule and delivered in half the time of the shortest possible schedule predicted by standard software models," which could suggest they had to rush their work.
The CLE is used to perform a wide variety of command and communications functions, everything from:
1. Communication with the BMC3 system,
2. Interceptor launch guidance, control and reporting,
3. Interceptor flyout communications and monitoring,
4. Controlling and monitoring electrical power,
5. Environmental and health and safety monitoring and control.
It's a very important system. For example, among other things, it calculates the engagement geometry and solar angles, retrieves data about the target, generates discrimination data for the interceptor, and tells the GBI where to go and what to look for. The CLE is an important part of the brains of the overall system, and is a "system-of-systems" itself. It also takes the info from the C-band beacon - a targeting aid that no enemy would provide -on the target reentry vehicle to create the first Weapons Task Plan, defining the basket out in space where the interceptor is aimed.
Obering is implying that the failure was on the ground, and so the interceptors are OK and don't need to be pulled out of the ground and fixed. But that remains to be seen since the CLE is itself an interfacing system aboard the interceptors and with computers on the ground.
I also read Obering's comments about message drop out rates as suggesting that they also had a problem with the 1553 data bus on board the interceptor. Boeing and Northrup have had lots of problems with the CLE/1553 interface. Basically, the 1553 data bus is too slow and doesn't have the capacity to handle the tons of information the interceptor has to process. Orbital has been worried about it ever since they got into the competition with Lockheed for building interceptors, and wanted to start over with a brand new type of data bus on board the interceptor. Orbital got a "waiver" so they wouldn't have to use it on Boost Vehicle Test #6 (BV-6).
But MDA and Boeing, thinking short term rather than long term, have hung on to the old data bus, hoping they can make it work.
Originally designed for electrically noisy environments in military aircraft, in practice, the 1553 is simple - basically two shielded wires running the length of an aircraft with multiple taps. In practice the 1553 is a millisecond oriented data bus. This is because a 1553 bus can have tens of microseconds of timing unpredictability, or jitter, in how long a data or instruction "hand shake" can take or vary. The 1553 is a half-duplex protocol, meaning that it can transmit messages in one direction or the other, but not in both directions simultaneously. Sort of like the old radio transmissions where you had to say, "Over."
A millisecond oriented data bus is too slow when your talking about very high speed systems such as missiles going thousands of miles per hour.
If you're handling very high data rates in a system that is moving very fast, a 1553 data bus can simply be "too slow" or too uncertain, and some messages won't get through or will drop out.
The crude analogy is the difference between 3 mph, 30 mph, 300 mph and 3,000 mph. At 3 mph you need shoe leather. At 30 mph you need wheels. At 300 mph you need wings or airfoils, and at 3,000 mph you need rocket propellant. A 1553 data bus in a high-speed missile system can be like trying to go 3,000 mph on shoe leather.

THERE'S MORE: "The Pentagon may never publicly declare that its new missile defense system is fully ready to defend against long-range missiles aimed at the United States," according to the AP.
Story Continues
Missiles DefenseTech DefenseTech