backtop


Print 61 comment(s) - last by rcc.. on Apr 1 at 4:26 PM


The B2 Bomber's radar frequency was recently sold to a Russian entrepeneur on accident. The incident emphasized the military's increasing spectrum woes.  (Source: U.S. Air Force)

The F22 Raptor's AWACS targeting probably won't work outside the U.S. This is just one of the many costly spectrum issues the Air Force and armed forces are having in the U.S. as civilian spectrum use increases.  (Source: Wikimedia)
Costly blunders and redesigns all part of military networking growth pains

The U.S. military originally had a virtual monopoly of certain communications channels.  It was one of the few entities to be using internet, and it used many areas of the spectrum untouched by civilian communications.  However, with the digital revolution and the expansion of civilians onto the internet and increasing using of the digital spectrum, the military is finding adapting to the deprivation of these bands difficult.

Last year during the bandwidth auction, the portion of the spectrum used by the B-2 bomber's Raytheon APQ-181 radar was accidentally sold to an obscure multinational organization according to Military.com.  As a result, U.S. taxpayers will be footing the over $1B USD bill to replace the radar in the 20 remaining jets.

With users demanding video-ready smartphones, high-speed mobile internet, and other emerging applications, the military is finding that the spectrum is quickly disappearing, and it’s having trouble finding areas for its own sensitive technologies.

Other expensive losses abound.  The Joint Tactical Information Distribution System, a costly system used to get AWACS targeting data to F-22 fighter jets has "limited supportability outside the continental U.S."

Another key issue is the steady creep of civilian communications into the spectrum used for flight-test telemetry.  While there are workarounds to gather some additional information, telemetry data remains essential to testing both manned and unmanned aircraft and protecting pilots from failures.

Ultimately, more data takes more bandwidth -- an unalterable fact -- and to achieve higher frequencies more power is required.  This places inherent limitations to the amount of data capable of being communicated over the spectrum.

Military designers are in a sticky situation as they can't compress their data, in many cases, like civilian applications.  "This is not a cell phone,” said Darrell Ernst. "You can't ask the pilot to wait while you redial."

Ernst works for the Mitre Corp., a member of a U.S.-European delegation trying to raise international awareness of bandwidth issues, and estimates that by 2020 the Air Force will need 600 MHz of spectrum for telemetry data.  Currently the only vacant spot suggested to them is the 5091 and 5150 MHz band.  The Air Force is eager to occupy even this meager 59 MHz offer.  States Mr. Ernst, "If [the flight-test community] can get in there and start using it, we can be established as the primary user and it will be hard for them to throw us out."

When it comes to the spectrum issues, there are few good answers, just more fears and doubts.  As a final example of the industry problems, when the Joint Strike Fighter (JSF) test program is flying two missions no other combat aircraft will be able to fly in the Western U.S.  States Mr. Ernst, "They're the 600-lb. gorilla. They don't see that they have any reason to move, and they don't have the radios to do it."



Comments     Threshold


This article is over a month old, voting and posting comments is disabled

RE: Why can't they compress data??
By Alpha4 on 3/23/2009 12:54:24 PM , Rating: 1
I'm guessing telemetry data can't be compressed because even a 1 millisecond delay to decompress it could compromise a target acquisition and cause even a tiny mis-alignment for precision targeting.

I remember an article discussing the "Surveillance Target Attack Radar System" (STARS) system and how it was completely written in assembly code to minimize processing time. That's probably consistent with all military software, though.


RE: Why can't they compress data??
By barjebus on 3/23/09, Rating: 0
RE: Why can't they compress data??
By Lord 666 on 3/23/09, Rating: 0
RE: Why can't they compress data??
By hyperbolicparody on 3/23/2009 2:42:25 PM , Rating: 4
Ada is still used extensively for aircraft and DoD applications. OFPs are still often written in Ada83, as are a lot of the military flight and ground simulations (both for testing and training purposes) out there, and I think it's a total shame that it wasn't until recently there was a free compiler (GNAT has come a long way in the past few years).

I actually wouldn't be surprised if the data coming off of the OFPs would be remarkably hard to compress. Working on them... hooks for simulation, test and debug are such an afterthought... the engineers are primarily focused on the insane flaming hoops they must jump through to get everything written, verified and approved.

There's rarely ANY overhead written into the hardware specs, and the components are horrifically sensitive to timing requirements. It makes non-normal operation rough... you might find your component locked out of the MS1553 bus (or even worse designed to self-destruct) if it's cycle count is out-of-whack with other components. But that's all done to make components pulled from crashed aircraft useless.

Also, it's tough to compress data fast enough on the hardware available. It's not the size, it's the volume, and it's the hardware on the aircraft. Gathering and packaging all your data at deterministic rates higher than 200Hz is harder than you think... and need all that data transmitted to the ground station with as little transport delay as possible. Also, imagine trying to do all of that on the embedded hardware available to you 10 years ago.

...oh, and some of it is written in FORTRAN. FORTRAN!


By lotharamious on 3/23/2009 3:25:40 PM , Rating: 4
quote:
...oh, and some of it is written in FORTRAN. FORTRAN!

What's wrong with Fortran? It's a powerful computation language. Unless you're talking about something prehistoric like Fortran 4.


RE: Why can't they compress data??
By rcc on 3/23/2009 4:15:40 PM , Rating: 1
True, but anything that is mission critical, or time critical, gets an automatic exception to the requirements for Ada.

For that matter, if you can claim COTS (commercial off the shelf) you can get an automatic exception.

Ada isn't fast, and it isn't small.


RE: Why can't they compress data??
By eachus on 3/24/2009 5:12:33 PM , Rating: 2
True, but anything that is mission critical, or time critical, gets an automatic exception to the requirements for Ada.

I wish I thought you were joking. Just about everyone who works on safety-critical systems, including mission critical systems, now knows that the only sensible choice is SPARK. SPARK is technically a subset of Ada, but the subset of interest is that programs in Ada that cannot be proven correct are not valid SPARK. Even if the Ada compiler produces no errors or warnings, the SPARK Examiner will reject any program, or module, as incorrect or ambiguous if it can't be proven correct. The savings from using SPARK on just about any large program are significant, and it results in even larger savings in safety-critical systems.

Check out this article: http://www.stsc.hill.af.mil/crosstalk/2002/03/amey... on the C130J project. The author said: In my 10-plus years of using SPARK, I have never needed to use a debugger. I have become so used to things working the first time that my debugging skills have almost completely atrophied. The only price I pay for this is the SPARK Examiner pointing at the source code on my terminal and displaying messages telling me I have been stupid again; I find I am grateful for those messages!

The author works for a company that produces SPARK tools, but I can vouch for the above. The only two times in the last 20 years or so of programming in Ada that I have had to use a debugger, the error turned out to be in Solaris. No, I am not knocking Sun or Solaris, and both of those (obscure) bugs have since been fixed. But I knew my program was correct, so the bug had to be in the OS. ;-)

As for efficiency of Ada programs, lots of studies have shown that the code produced from Ada programs identical to the C version are much the same, assuming you chose the right compiler options in both cases. GNAT for example has an option to avoid loading--or using--any compiler run-time. Slower and bigger if you write programs which make heavy use of the run-time, much faster and smaller otherwise.


"If a man really wants to make a million dollars, the best way would be to start his own religion." -- Scientology founder L. Ron. Hubbard

Related Articles













botimage
Copyright 2014 DailyTech LLC. - RSS Feed | Advertise | About Us | Ethics | FAQ | Terms, Conditions & Privacy Information | Kristopher Kubicki