F22 Raptor: Source code crashes lead to problems in system software.

Strategypage ^ | April 2, 2004

[Oztrich Boy]

OK Keeping the principle, but more like a warplane that might have been.

[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 ...

[Myrddin]

Sounds like you folk ran into that nasty ISO-900x certification.

Probably not on this project. Yet.

I was part of the "coding wars" studies that formed the basis the "Peopleware". It was a fascinating project. That was in my PacBell days. The "Dilbert" books were written by a co-worker at PacBell. I read his work and laugh. The stuff is a parody of real people. The company insiders have a clue about the real people. The "outsiders" just get a hell of a good laugh at the shenanigans of "corporate climbers" inflicting the latest pop methodology on the company staff.

[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.

[cpdiii]

When it absolutely without doubt has die today:

CALL THE F4 PHANTOM

[AgentEcho]

LOL!!! That was the exact aircraft I had in mind when I read that line.

Æ

[Myrddin]

Real time embedded stuff tends to be built on top of APIs such as PSOS or VRTX. That gives you the ability to have multiple "tasks" with hard real time and pre-emption. It doesn't make sense to keep reinventing that wheel each time. There is a place for writing assembler to manipulate device registers and performance of "atomic" operations such as "test and set" cells that guard a common resource.

Current high performance processors depend upon a pipelined execution queue. Optimized compilers can create better "pipeline" code than most "skilled" programmers in assembler. A pipeline stall created by a careless choice of operations will trash the execution performance on that kind of CPU.

[Spruce]

The challenge is when to re-write. I have always based this on a Kludge/code ratio. When Kludge gains a foothold and becomes the standard, you re-write. It would seem they have hit that wall.

[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?

[mikegi]

I've been in this business for almost 20 years and hate to say that most developers write pretty poor quality code.

Funny, isn't it? It always seems to be the other guy who writes sh*tty code. I pity the poor soul who had to take over my code!

[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.

[mikegi]

Current high performance processors depend upon a pipelined execution queue. Optimized compilers can create better "pipeline" code than most "skilled" programmers in assembler. A pipeline stall created by a careless choice of operations will trash the execution performance on that kind of CPU.

Back in the old days it was easy to beat a compiler. Nowadays, it's much more difficult. Plus, CPUs are so fast that it makes no practical difference in most cases. However, there are a few applications where it still makes sense to use asm. For example, crunching large bitmaps. Compilers seem to have trouble with the nasty bit fiddling you do when crunching bitmaps.

[Myrddin]

Today's CPUs can be absolute dogs with a bad compiler. The blazing fast execution is as much a consequence of an optimizing compiler as it is a "fast" CPU. It takes both in concert to achieve the speed.

I agree with respect to bit twiddling a complex bitmap. The "simple" stuff that can be accomplished with mapped bitfields inside a C struct is fine for most modern compilers. Unfortunately, you get compiler dependent implementations that don't port nicely.

[Light Speed]

I must admit that I am fairley ignorant as info goes on code writting process.
However...am aware from other science applications..especially the field of Feild/Harmonics..shielding to contain energy..where the threshold is processor speed and tasking reaction code/software..as they try..and try is the key here..for the processor speeds needed are phenominal to keep feild harmonics from collapsing..
in this field of endeavour..they are achieving amazing things with computers.
if a system is to be productive for the future..and flexible to the new abilities that are soon to come...ie..Mag rail launch...Scramjet engines..etc.
then it makes sense to go for code writers who are working with these new technologies..and dump the old ways.
I imagine DARPA...JPL/NASA are the guys to get on the team..allong with the techs who are writing code for these new science systems.
raise the bar..put something in that aircraft that will make it workable for future mods ...tasking...and interface

[pt17]

I have been programming IBM 360 Assembler for 16 years.

I was fascinated, IronJack, to learn 360 BAL is still in use. It must have some legs since I was programming in that over 30 years ago.

[X_CDN_EH]

IronJack, you're rather behind the times. S/360 went out of date many years ago. We're past S/370 and on to S/390 and even Z/OS now.

Z/OS, the 64 bit MAINFRAME Operating System.

Windows is a joke.

Regards.

[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.

[CasearianDaoist]

Gig you know that they are chucking ADA for C++ on the Future combat system?

[CasearianDaoist]

Gig=did; Also there are ADA/C++ cross compilers. I know some of the people on the F22. It is going well this is just the usual caring. They are just rolling out the production bugs, the problems are mostly on the targeting acquisition system and some avionics integration issues, this process started less them 3 years ago. The "image" (as in radar) recognition system is having some problems. This is not unusual. The software architecture is wonderful and the avionics world is plenty of good ADA people, It is not a very hard language to learn, Real time concepts applied ot avionic is what is difficult. These isyems have there own Air Force/vendor "operationg systems" (perhaps morw aptly called "operating environments") it is unclear how whiching to another language is helpful

There is a real anti-f22 lobby, and it seems to originate in the Democrat party, at least in the US. The f22 is revolutionary and gives us an amazing edge over any other Air Force. Some people really do not want this. It will be fine if the program is allowed to go ahead.