Slashdot Mirror
F-22 Avionics Require Inflight Reboot
An anonymous reader writes "The Atlanta Journal & Constitution is fronting a lengthy piece on the USAF's new F-22 and its upcoming shootout with the existing fleet of F-15's & 16's. One line in the article really jumped out at me: 'When avionics problems crop up now, pilots must restart the entire system as if rebooting a personal computer.' I did some googling, and this is about as much as I could find: The hardware backbone for the system is the Hughes Common Integrated Processor, which, in turn, appears to be built around the Intel i960 CPU. I couldn't find a name for the operating system, but it appears to be written in about one and a half million lines of Ada code; more on the Ada hardware integration and Ada i960 compilers is here. Any Slashdotters working on this project? If so, why do you need the inflight reboot? PS: Gamers will be interested to learn that nVidia's Quadro2 Go GPU and Wind River's VxWorks Operating System are melded in the F-22's Multi-Function Display."
Sorry, but if you have to reboot the ENTIRE avionics system of a F-22 you're fucked to say mildly.
;)
This plane is always in a controlled stall, the movements of the rudder to prevent it from crashing are calculated every second this bird flys, the pilot just decides in which directions the plane goes, but the task of keeping it up is left to the CPU.
So, if you just "reboot" this sucker for a second the plane would plummet like a stone, no matter how strong it's pushed forward by the engine or what the pilot does.
What I can imagine that the pilot would have to restart some none vital components of the main computer.
Such as the timing of the green/red flashlights or his seat heating.
Even restarting the RADAR/TARGETING unit would be ok, BUT DO NOT SWITCH OF THE AVIONICS ON THIS BIRDY!
In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion. Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't. I don't know anything about the F22, but it's easy to imagine that it has hundreds of input sources with all sorts of latency requirements. AFAIK, it all comes down to some humans trying to balance these conflicting needs. Clearly they don't always get it right.
The flight control computers are 7x redundant and distributed throughout the airframe. It's the new radar and v3.0 combat avionics that need "rebooting"
If voting were effective, it would be illegal by now.
"Now this is more of an MS bash... people have come to expect system failures, and I've read admissions that 5-9's uptime is just too difficult and expensive a goal, and so-on, and of course this mostly points to MS desktop and server software"
;)
That's an interesting read, my company chose Windows 2000 for stability as desktop machines, and we're doing fine. 19 desktops and laptops, all running 2k. My job is to maintain them, and I find way too much time to post on Slashdot.
We've also got an NT4 webserver running IIS, and it's been up for 3 months. It would have been up longer except I had to shut the box down to move it.
I'll tell you something, it was a huge relief to go to 2000 from 98. Nobody bugs me about anything anymore. We have computers running all weekend processing video data. We haven't had an 'over the weekend crash'. We'll have 4 video files going at once, two per processor, and they'll all be done by Monday. As you can see, we beat our machines pretty hard sometimes.
*Thought it'd be nice for you to hear from somebody who's had good experiences with MS for a change.*
I've drifted off topic a bit. Sorry. The point I'm basically making is that Windows 2000 is a fine OS and would probably be up to the job, at least run-time wise. I know that comment's going to draw criticism, but oh well. I've worked around a ton of these machines for the last two years and you're not going to change my mind about it. Heck, I have a computer in my bedroom right now capturing TV shows as a home-brew Tivo. Hasn't been rebooted in over a month. Not bad given how buggy the TV drivers are. Heh.
> This means the developers were forced to use
> Ada, but why ? To me, it seems some suits think
> it's especially "safe" for some reason, does
> anyone know more about that ?
Ada is especially safe. It is, in fact, one of the
VERY few safety critical environments you will
find. It's very simple- A safety critical program
must never exit and give up control functionality
entirely, no matter what happens. There are many
things that you can do with C/C++/Java that will
cause a crash unrecoverable by the system.
Ada is designed to inherantly prevent a programmer
who follows the appropriate standards from writing
a program that can just crash and exit. As long as
every possible exception has a handler, an Ada
program can be written that will not crash.
> But I think you can try to make a programming
> language as "safe" as you want, it won't prevent
> you from implementing bugs, it just causes a
> false sense of safety instead which can be even
> more dangerous, IMHO.
Bugs are universal. But bugs in a C program can
cause the controlling system to shut it down with
prejudice (Sig 11 and others), and it doesn't
offer the automatic safety nets Ada does. Can you
write safety critical software in C/C++/Java?
Certainly. It's all a matter of methodology. Ada
enforces the methodology, which is why people hate
it. They can't do cute, horrible hacks like they
can in C/C++, and Ada requires explicit
specification.. Ada has specific standards of
implementation for software, and a good inherant
design. It is designed, from the ground up, as a
'safety critical' language, and for the most part
succeeds on its own merit.
I do understand the widespread animosity towards
Ada. People don't like the verbose, very specific
code. Progammers often want to bend the langauge
over their knees and perform horrid hacks that
make reasonable people blanch in fear, but Ada
doesn't really allow that. Programmers are often
forced to learn Ada in structured learning
courses, and forced to read the Ada RM. They end
up hating it because of the language and
terminology used, because of the verbosity of the
language, because of some of the difficult
concepts of Ada, etc..
But it really is a fine language. (I'm sure many
people will disagree with me without really having
an objective or informed viewpoint, but that's
just how it goes)
-Kysh
--=:: Wings and tail and snout and scales of blackest night
In what way is Ada better than Java in this respect? I only know a little about Ada, so this is a serious question. My understanding is that Ada and Java have very similar safety goals (especially with respect to exceptions) so I'm curious about what you think Ada gets right and Java gets wrong.
It should be the case that the only way for a Java program to "crash" is if there is a bug in the runtime library or hardware interface: the same kinds of problems can of course affect Ada.
(I've got a lot of problems with Java, mind you, but I'd never say it was "too lenient"...)
You act as though C is responsible for a stack overflow or pointer pointing problems.
You wanna know something: IT'S THE PROGRAMMER.
You can write huge applicatations in plain ANSI C. They can run flawlessly. As long as you use good programming practices and have good programmers.
Excepting buggy compilers or libraries (very rare in my experience), when you write something in C and it doesn't work, it's your fault. C is very simple, elegant, and deterministic. For examples of C programs that work very well, see UNIX OS kernels, most of the system tools on UNIX, and especially TeX.
You can write perfect programs in some "more modern" languages ("safe" languages like Java) that will crash, because the environment is so complex that many environments are buggy. This is unacceptable. Not only that, most of these languages aren't any better than C as far as memory management (That's why all the Java programs I see crash with "NullPointerException").
These new languages, however, do increase the overhead of a program running, to make things slower. As a computer engineer, I do like that feature, as it means that people will go out to buy more complex hardware.
There are some programming languages that really do have features that help write very very stable, unbuggy code. I would say ADA, ML, and LISP fall in these catagories. But even in these languages, the language can only do so much. In the end, your program will only be as good as your programmer.
Actually, we have gotten out of the use of functional languages like LISP and replaced them with procedural languages like C. Which is good! That's what your computer does anyway. Though most functional languages do a very good job of implementing themselves in a procedural system... stacks are pretty simple things.
But I bet you're one of those OO people. You think that OO is the greatest thing and that if everyone used it to write their programs, the world would be a fantastic place.
There's a place for OO languages. They do some things well. Some things they do very badly. And in the end, OO languages are still only as good as the programmer. And they have enough problems and complexities that for things like flight control, they aren't always appropriate.
Let me tell you a little story. There was once a class that was trying to make a robot arm play ping-pong. There was a camera that could see the ball, and then the software computed where the paddle should be, then was supposed to move there so that the ball would return to the other side. The software was written in a "safe" language.
When they went to test the robot arm, the ball flew straight past it. The arm didn't budge. They looked at each other, wondering what the bug was, until a few seconds later the arm moved to where it should have gone.
The problem was the environment. After doing the complex computations, the garbage collector decided it needed to clean up all the memory used for the calculations. Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.
And to finish off, let me tell you the one thing that bugs me about most languages: THEY DON'T HAVE BUILTIN MACRO PROCESSORS. Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.
-- Erich
Slashdot reader since 1997
First, read Kysh's comment. It's better than mine.
But the short answer is that it's possible to compile a Java program that will exit due to an uncaught exception. For many exceptions, Java forces you to have an exception handler, otherwise the code won't compile. But not for all. Runtime exceptions can send your code straight out the window.
The idea behind Ada-- I've never done much Ada programming myself-- is that it's not supposed to be possible to compile code that can throw an uncaught exception. The compiler is supposed to prevent you from doing such a thing.
This doesn't mean that Ada code is always perfect, but it does give you a degree of freedom that you don't get with other languages.
I did some work about four years ago on a flight simulator project for the DoD. The first stage in the project was to build an unclassified demonstration version of the new sim. Some code related to weapons-- in this case, the AIM-120 missile-- is classified, and can't be demonstrated in an unclassified environment. So what did we do? We just didn't link in that code. (I may have my terminology wrong; I was doing HSI, not code, so I'm just going by what my friend on the other side of the hall told me.)
With any other environment, C or Java or whatever, that would have resulted in a fatal runtime error. But Ada doesn't let you have runtime error situations without exception handlers, so when it encountered the missing chunk if AIM-120 code, the sim just dropped into the exception handler-- which basically said, ``never mind, everything's fine''-- and kept right on going. The sim dropped a couple of frames every time you fired a missile, but other than that, no problem.
I've gotta say that I found that pretty cool. I mean, the sim just kept on going, after it found that a huge chunk of important code was simply missing! Neato!
The garbage collector in java is an asynchronous type. This means while it is running its collection procedures (which can begin at any time, there is no way for the programmer to control this), processing of the program code halts.
I had a professor which demonstrated the problem of this in a simple example. Suppose you are designing a robot which can climb and descend stairs. It must monitor sensors and adjust angles of its joints appropriately to go down (quite difficult, really). Now suppose the GC runs halfway through the middle of a step. All processing stops, gravity takes over, robot falls down.
Same goes for avionics systems, if you're landing a plane, you don't want your HUD display to suddenly freeze as you're descending at several meters per second. You'll descend straight into the ground.
Hence the reason java puts a clause in its license about no use in safety-critical applications.
-
not bozos, it's the government guidlines. For instance the fuel systems have redundent processor units. when started both are online with the slave electronicly disconencted. Following FAA guidlines dictates that a one strike and your out is enforced. At the first sign of CPU trouble (crash,freeze,any electronic part failing within the system) all inputs and ouputs on the unit are sent to high-z and the other unit takes over. Now the reboot part, the first unit will sit in a frozen state indefintly until it is manualy reset with a POR or full HR. But the plane will fly just fine on the redundent system. In an emergency the pilot can manualy reboot the halted system and it will either start up again (if the inital failure was some glitch) or immidiatly halt again if it was a critical falure.