[spetznaz]

My only question (and maybe some Freepers with necessary knowhow can answer this) is why the F22 software cannot be upgraded. How difficult would it be to replace the flawed software with something more up to date .....even something that is off the shelf? I guess that is a rhetorical question since if it was simple it would have already been done, but i am still curious as to the degree of difficulty imbedded in such a decision. And even if it is difficult i am certain it would still be more cost-effective than having the most expensive fighter jet being wracked by flawed software. Or so it would appear, but the fact this is an issue inherently implies that it is not so straight forward.

Any freepers with an explanation for this?

[Support Free Republic]

---

Calling All Freepers
	Donate Here By Secure Server Or mail checks to FreeRepublic , LLC PO BOX 9771 FRESNO, CA 93794 or you can use PayPal at Jimrob@psnw.com
STOP BY AND BUMP THE FUNDRAISER THREAD- It is in the breaking news sidebar!

[spetznaz]

F-22 Raptor Ping (software problems).

[Spruce]

The classic software dilemma. When does the Kludge end? When can we re-write this crap?

[HamiltonJay]

There is nothing off the shelf about the F22's software. Custom one of a kind hardware, and custom routines to control every aspect of the plane.

I work for a company that is doing many research projects for nasa and the military, some really cutting edge stuff... and stuff that will save lives.

The F22 software is what I would call evolutionary obsolete. Meaning that it has evolved over time, while requirements continually changed for it... leaving a hodge podge of kludgy code, none of it designed or architected from the top... and what is not running is nothing like anything that has been designed in the grand scheme.

THe original coders are likely long gone, new code is being hooked into old code that no one understands, new requirements and features require even more code to be put on top of that... etc etc etc...

What needs to be done is a complete rearchitecture and rewrite of the entire system. A costly undertaking that RARELY happens to software once it is in a production environment. At least based on the story as told in this article.

[cooldog]

There is nothing "off the shelf" available, that's why.

This code was custom-built for one job only; controlling a Raptor F22, and it's the *only* code in existence for the job.

If it is as bad as this article says, then a rewrite is in order.

[coloradan]

[Spruce]

Could you imagine having to extend proprietary code written over 2 decades? Before terms like Inheritance, Extends and Polymorph were even parts of the toolkit? What a friggin nightmare. It would be a blast, though.

[mikegi]

How difficult would it be to replace the flawed software with something more up to date .....even something that is off the shelf?

It can't be replaced by something off the shelf. Rewriting code always seems like the Holy Grail but the problem is that it's ALWAYS more difficult than it seems. All the old hard lessons have to be learned all over again. Things in the old code that look stupid may actually have an important purpose. Having said all that, I have rewritten large chunks of old code and made it much cleaner and easier to work with.

I definitely would not want to be responsible for custom software that sits on top of constantly changing custom hardware. Especially in a real-time system. Tight timing requirements in an RT system make using an off the shelf OS kernel less likely. The benefit of using an OS kernel is that it would force the software to be organized in an app->kernel->driver model. Better have a damn good scheduler in the OS!

One last note, I have no idea how the F22 software is organized but I suspect that the failure "every 90 minutes" is not a system crash but a less serious problem like a timeout in a non-critical system.

[Myrddin]

A project started at my company in 1993. It was a classified DoD project that mandated use of ADA. By 1998, the project had consumed $75 million and produced a hodge podge of trash. The project required 2167 documentation standards. That meant almost 10 pages of documentation for every page of source code.

DoD became impatient in 1998 and directed the project manager to switch to C++. He dutifully obeyed and turned his lame cadre of Ada "engineers" into an army of feckless C++ hackers. The project is still in the toilet today. The original "senior" "Ada engineer" disappeared back into the hole from whence he had appeared.

Thankfully, my total involvement in that fiasco was just a couple project review meetings. Yuck. I'm not sure that I would be anxious to be an F-22 pilot.

[Izzy Dunne]

Source code crashes lead to problems

Maybe they should COMPILE the source code before they run it...

[GeronL]

Windows F22 Patches are on the way!

[IronJack]

All source code ultimately gets compiled down to machine language, the binary code that actually runs when the program is loaded. It doesn't matter if the source is ADA, C, BASIC, Pascal, or COBOL, it all ends up as machine code.

I have been programming IBM 360 Assembler for 16 years. It's as close to machine language as you can get without actually writing the machine op codes. I imagine the machine language for the F-22 microprocessors could also be written in native Assembler.

But I suspect machine language programmers are harder to find than ADA programmers.

However, I DO know one with at least 16 years of experience ...

[jrp]

Developing reliable, high-quality software, especially for a complex, hard real-time embedded system is massively labor intensive and very much depedent on the knowledge and skill of each of the software engineers. It's not too much of a generalization to say that one lousy developer can jepordize the reliability and reputation of an entire system.

I've been in this business for almost 20 years and hate to say that most developers write pretty poor quality code. I've had to throw away a lot of it, not because I couldn't understand it, but just the opposite. I knew all too well that it deviated so far from good software engineering practice that no amount of tweaking and patching would ever make it reliable or maintainable. In those cases, it usually made more sense to rewrite it. Of course, that's a much easier decision to make on a small project than something the size and scope of the F22 avionics code.

[Jorge]

I thought the DOD had decided to put the overpriced Raptor on the back-burner for now in favor of the Joint Strike Fighter?

[merry10]

I have a long and boring answer. Not only can you not just pick up something off the shelf, but you have to take firmware versions into account, for one. The firmware inherent in a part needs to be compatible with the other parts' firmware and also needs to be able to run with the operating system of the particular weapons equipment. Then throw parts obsolescence into the mix...you know how computers are made to go faster every year...a system also needs to keep up with technology. The option is to use old parts, and that is no good due to shelf life. A part in the F22 system may not be made in two years, so you have to find a part (project that part) that will be made and do compatibility testing. All very boring, I know. Once the system is ready to be fielded, Test and Evaluation processes must be applied. This could take years, and all the while you're upgrading software and looking for compatible parts etc, etc. Even if it would be more cost effective to use off the shelf Software, one of the reasons it is extensively tested is because of the safety factor. There are whole entire groups of DoD civilians devoted to weapons safety. Used to be that this process would take a lot of years from conception to fielding; then Clinton's Secretary of Defense shortened the timeframe to help get the systems out to the field faster; Rumsfield has recommended and wants to implement even a faster approach. Sorry for my digression.

[quietolong]

Let's see now... The F16 flies, So does the F117 & the shuttle And a number of other experimental aircraft that are aerodynamically unstable. And can not fly without the use of a computer.
The software for this has already been written and works. It's a known.
Could it be that they FIRED there old engineers and programmers. And are using youngsters without some of the old fart's guidance and experience? Just so CEO's can line there pockets. With a little of good old PC. To round everything off.

[jennyp]

Sounds like someone needs to send a copy of Steve McConnell's Rapid Development to each project manager & analyst over there.

[Fresh Wind]

There's never enough money to do the job right the first time, but there's always enough money for years and years of band-aid fixes.

[Aeronaut]

[Pyro7480]

I'm not overly concerned about the software problems the F-22 program is having. Back in the late 80's and early 90's, when the AMRAAM missile was being developed, the fact that the missile didn't have adequate software so it could work properly almost killed the project. However, at almost the last minute, they were able to write the software for it to work. In the first 3 test fires after the software arrived, they got 3 kills on the test targets. When the AMRAAM was deployed for the first time over the skies of Bosnia, the Air Force got similar results. Air Force pilots now compare the ease of firing the AMRAAM to killing baby seals with a club. ;-)