MISSILE DEFENSE “GLITCH?” YEAH, RIGHT

Everything is work­ing per­fectly. There is noth­ing — repeat, noth­ing — to worry about. The rea­son the mis­sile defense sys­tem flunked it’s most recent $100 mil­lion test? Just a “very minor” soft­ware glitch, insisted Missile Defense Agency chief Lt. Gen. “Trey” Obering. It was incon­ceiv­able, Obering told the Washington Post, that such a prob­lem could ever, ever hap­pen again. The Ground-​​based Midcourse Defense sys­tem may have face-​​planted this time. But against a real mis­sile, he promised, it was absolutely sure to work right.

Providing the first detailed account of what went wrong, Obering told reporters that the count­down was auto­mat­i­cally aborted when a rou­tine sys­tem check of inter­nal elec­tronic sig­nals detected a poten­tial prob­lem. The check showed that too many elec­tronic mes­sages had been missed in the sig­nal flow between the flight com­puter and the unit that con­trols the interceptor’s thrusters.
In ret­ro­spect, Obering said, design­ers of the inter­cep­tor had imposed too tight a limit on the num­ber of allow­able missed mes­sages.
“It turns out we had overly con­strained the sys­tem,” he said.
Obering called the chances of such a glitch occur­ring “very rare.” If it had hap­pened dur­ing an actual cri­sis, with an enemy mis­sile head­ing toward the United States, the sys­tem would have sim­ply bypassed the faulty inter­cep­tor and launched another one, Obering said. 

Sounds rea­son­able. But Philip Coyle, the for­mer head of the Pentagon’s office of Operational Test and Evaluation, isn’t buy­ing it.
First of all, Coyle noted, the tests that the anti-​​missiles keep flunk­ing are way, way over-​​simplified. In the December trial, called Integrated Flight Test (IFT)-13C, the tar­get was fixed with a radar bea­con and GPS loca­tor, mak­ing it pretty damn easy to spot.
More impor­tantly, per­haps, is the fact that there’s only one tar­get. If Kim Jong Il is ever steamed enough to lob mis­siles 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 mis­sile defense sys­tem — one that’s had a whole bunch of prob­lems in the past. Click here to con­tinue on, as Coyle looks at just how sig­nif­i­cant the anti-​​missile system’s prob­lems really are.

For more back­ground than you could pos­si­bly want, rumor has it that the fail­ure in IFT-​​13C was in the CLE. CLE is short for Command Launch Equipment. It’s a big com­puter sys­tem and part of the Ground-​​based Interceptor (GBI) Support System. Lots of soft­ware is in the CLE sys­tem, and they’ve had sig­nif­i­cant prob­lems with that soft­ware. Part of the CLE is on the ground and part is in the inter­cep­tor.
It’s built by Northrop Grumman, and, accord­ing to their web­site, “con­trols the inter­cep­tor through launch, pro­vid­ing near real-​​time tra­jec­tory plan­ning, com­mand­ing, and health and sta­tus mon­i­tor­ing.“
Northrup says, “The CLE soft­ware was devel­oped on a highly accel­er­ated sched­ule and deliv­ered in half the time of the short­est pos­si­ble sched­ule pre­dicted by stan­dard soft­ware mod­els,” which could sug­gest they had to rush their work.
The CLE is used to per­form a wide vari­ety of com­mand and com­mu­ni­ca­tions func­tions, every­thing from:
1. Communication with the BMC3 sys­tem,
2. Interceptor launch guid­ance, con­trol and report­ing,
3. Interceptor fly­out com­mu­ni­ca­tions and mon­i­tor­ing,
4. Controlling and mon­i­tor­ing elec­tri­cal power,
5. Environmental and health and safety mon­i­tor­ing and con­trol.
It’s a very impor­tant sys­tem. For exam­ple, among other things, it cal­cu­lates the engage­ment geom­e­try and solar angles, retrieves data about the tar­get, gen­er­ates dis­crim­i­na­tion data for the inter­cep­tor, and tells the GBI where to go and what to look for. The CLE is an impor­tant part of the brains of the over­all sys­tem, and is a “system-​​of-​​systems” itself. It also takes the info from the C-​​band bea­con — a tar­get­ing aid that no enemy would pro­vide –on the tar­get reen­try vehi­cle to cre­ate the first Weapons Task Plan, defin­ing the bas­ket out in space where the inter­cep­tor is aimed.
Obering is imply­ing that the fail­ure was on the ground, and so the inter­cep­tors 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 inter­fac­ing sys­tem aboard the inter­cep­tors and with com­put­ers on the ground.
I also read Obering’s com­ments about mes­sage drop out rates as sug­gest­ing that they also had a prob­lem with the 1553 data bus on board the inter­cep­tor. Boeing and Northrup have had lots of prob­lems with the CLE/​1553 inter­face. Basically, the 1553 data bus is too slow and doesn’t have the capac­ity to han­dle the tons of infor­ma­tion the inter­cep­tor has to process. Orbital has been wor­ried about it ever since they got into the com­pe­ti­tion with Lockheed for build­ing inter­cep­tors, and wanted to start over with a brand new type of data bus on board the inter­cep­tor. Orbital got a “waiver” so they wouldn’t have to use it on Boost Vehicle Test #6 (BV-​​6).
But MDA and Boeing, think­ing short term rather than long term, have hung on to the old data bus, hop­ing they can make it work.
Originally designed for elec­tri­cally noisy envi­ron­ments in mil­i­tary air­craft, in prac­tice, the 1553 is sim­ple — basi­cally two shielded wires run­ning the length of an air­craft with mul­ti­ple taps. In prac­tice the 1553 is a mil­lisec­ond ori­ented data bus. This is because a 1553 bus can have tens of microsec­onds of tim­ing unpre­dictabil­ity, or jit­ter, in how long a data or instruc­tion “hand shake” can take or vary. The 1553 is a half-​​duplex pro­to­col, mean­ing that it can trans­mit mes­sages in one direc­tion or the other, but not in both direc­tions simul­ta­ne­ously. Sort of like the old radio trans­mis­sions where you had to say, “Over.“
A mil­lisec­ond ori­ented data bus is too slow when your talk­ing about very high speed sys­tems such as mis­siles going thou­sands of miles per hour.
If you’re han­dling very high data rates in a sys­tem that is mov­ing very fast, a 1553 data bus can sim­ply be “too slow” or too uncer­tain, and some mes­sages won’t get through or will drop out.
The crude anal­ogy is the dif­fer­ence 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 air­foils, and at 3,000 mph you need rocket pro­pel­lant. A 1553 data bus in a high-​​speed mis­sile sys­tem can be like try­ing to go 3,000 mph on shoe leather.

THERE’S MORE: “The Pentagon may never pub­licly declare that its new mis­sile defense sys­tem is fully ready to defend against long-​​range mis­siles aimed at the United States,” accord­ing to the AP.

January 14th, 2005 | Missiles | Comments Off Both comments and pings are currently closed.