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."
Boeing, responsible for integrating the F-22 Raptor's advanced avionics, has been testing software packages in both its avionics integration lab, or AIL, since 1998, and on its 757 Flying Test Bed, or FTB, since March 1999.
Both the AIL and FTB are helping reduce avionics risks and contain development costs by enabling extensive evaluation and troubleshooting before full avionics are ever installed on the F-22. Testing in the AIL and aboard the 757 FTB has allowed for early delivery of avionics Operational Flight Packages, or OFPs, to the F-22 test aircraft.
To date, Boeing has completed more than 21,000 hours of avionics testing in the AIL and 800 hours on the FTB.
Despite an accelerated delivery schedule for the year 2000 to support the Defense Acquisition Board, or DAB, requirements, the Boeing Avionics Integration team was able to integrate, test and deliver all Operational Flight Programs, or OFP's, ahead of plan. This included delivery of the Block 1.2 OFP on July 5, 2000, and Block 2/3S OFP on July 20, 2000. The AIL was also able to deliver the Block 3.0 OFP Engineering version to the Avionics Flying Test Bed aircraft a month ahead of schedule (Sept. 4, 2000) to allow for early testing and maturing of the OFP, which resulted in the first demonstration of multi-sensor fusion (Sept. 13, 2000).
The most significant accomplishment of the AIL for 2000 was the delivery of the Block 3.0 OFP, the first fully integrated avionics package, to F-22 aircraft 4005 on Nov. 21. This was a critical milestone since the Block 3.0 OFP was the first complete avionics software package to be flown on the F-22 aircraft, one of the most challenging DAB milestones accomplished to date.
The Boeing Avionics' Systems Engineering team's performance testing on the radar has resulted in all Test Performance Measurements, or TPMs, meeting or exceeding specification requirements. A significant milestone was reached on Nov. 15, 2000, when Raptor 4004 conducted its first flight, and targets were successfully detected and tracked in the air. Performance of the radar system was described as "eye-watering" by the pilot who flew the mission. A second major milestone occurred on Jan. 5, 2001, when Raptor 4005 flew for the first time utilizing Avionics Block 3.0 with the full complement of Radar Modes incorporated. Once again, targets were detected and tracked at long range, and the radar performance was outstanding.
Avionics Radar and Power Supplies Production activities continue to be a high priority. All shipments for PRTV I have been completed, PRTV II shipments are well under way, and hardware manufacturing for Lot 1 has begun. In the area of affordability, the implementation of Boeing-funded process improvements on several components of the radar/power supply systems, to include the T/R module and circulators, have been a tremendous success. The predicted cost savings have been substantiated in the first three production contracts and the targeted cost savings of $350 million dollars over the production life have been legitimized.
The next critical avionics milestone is delivery of Block 3.1 avionics. Block 3.1 will provide additional functionality to the F-22 Raptor and allow it to accomplish a significant amount of flight testing. Block 3.1 is scheduled to be delivered to Lockheed Martin this fall.
Overall, the F-22 avionics program is very much on target in the areas of performance, cost and schedule. The avionics packages have been performing exceptionally well, and all major milestones have been met on or ahead of schedule.
If voting were effective, it would be illegal by now.
Apparently, the reboot is only necessary after discharging ammunition. The hardware configuration wizard will pop up and instruct the pilot to reboot the system in order to activate the changes.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
If it requires an inflight reboot, there's no doubt what OS it's running. Gotta be Win98. I can see the MS tech support call now..
MS Support: "Thank you for calling Microsoft Customer support. How may I help you?"
Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'General Protection Fault' in white text on a blue background."
MS Support: "And what is the system model?"
Pilot: "The the F-22 jet.."
MS Support: "Oh yes, there are known issues that we will not admit to with that particular system. To temporarily fix the problem, simply reboot. Or, if the 5 minute boot time is too long, may I personally recommend that you eject. However, you will have to purchase another license of Windows 98 for $1000 since jet fighter crashes are not a valid reason to receive a new license."
Pilot: "@#$*(! Microsoft!"
MS Support: "Thank you and have a nice day!"
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!
Everyone knows that frequent reboots prevents crashes.
Sheesh, evil *and* a jerk. -- Jade
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.
It's so todays pilots feel more at home with their fighter jets computer of course, having grown up with 90's software. You haven't seen the changes to communication protocal yet have you?
typical conversation between pilots
pilot1: u missed ur target fag u suck
pilot2: stfu idiot i'll kik ur ass
pilot1: lol ill show u how to shoot missles loser... im gonna get that camper anti-aircraft fag
pilot2: haha u missed 2... u couldnt even hit ur fat momma
and so forth....
This comment was generated by a Squadron of Ultra Ninjas
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.
Sine, cosine? Assuming you have a line draw routine and a raster display, none of that is needed.
About fifteen years ago for a prototype heads up display I had the same exact problem: draw the tick marks for a compass rose with no memory and no time. There was no scaling of the circle, only rotation about a fixed center.
After some though, what I did was to store in a table the tickmark endpoints for 45 degrees of arc (I recall it being 22.5 and not 90 degrees) for all the displayable rotations of that arc. Then at runtime, my compass rose routine would exploit the symmetry of the situation to determine the endpoints of all the other displayable tickmarks.
It used very little memory since at any point in time we only displayed tick marks at 5 degree intervals. Therefore 45 degrees of those would be 9 tick marks, or 18 ints (two ints per tickmark). At 5 degree intervals with a resolution of 1 degree, you only need a table of 5 x those 18 ints, or 90 ints all told.
I always loved the 3am epiphany!
Also, can anyone confirm if OSA is the name of the referenced ADA software project (1.7 million lines etc...)
Gmanske.
MAVERICK
I've lost him -- where is he?
GOOSE
On your six -- coming hard. Four
hundred. Losing airspeed! He's on
your six and closing fast!
Hard left! HARD LEFT!
Maverick jerks the stick left, and the F-14 takes an
astonishing turn. Jester ROARS past into a wide arc.
GOOSE
Great move. Great
MAVERICK
He should've had me.
GOOSE
Take it down. Let's bug out of
here. Call for a draw.
MAVERICK
No way. Let's reboot. I'll nail him this time.
Going vertical.
One day, they asked "What is the most common cause of plane crashes?". I hastily and enthusiastically responded "gravity!!" I got in real serious trouble that day, I forgot that the teacher was also a pilot. The real answer was 'human error', which I had illustrated that day when my teacher shot me down to the principal's office.
> Software functionality should not be fundamentally different from hardware functionality.
Am I to understand that you are saying that software, like hardware, should only fail when it fails?
Granted, we have a software reliability crisis on our hands. But hardware isn't generally fault-free either. I've had a lot more Zip drives die on me than I've had kernel panics. And arguably a kernel is much more complex than the design of a removable disk drive.
> An algorithmic system is temporally inconsistent and unstable by nature.
That's an absurd claim. It's possible to prove correct behavior for algorithmic systems. Time is explicitly accounted for in most such proofs.
The biggest engineering difference between software and hardware is that people find software errors acceptable, or even normal, whereas they have never reconciled themselves to, say, collapsing bridges or wings falling off of airplanes. When that attitude changes we'll start seeing software that rivals hardware in reliability, not before. Most of the engineering concepts required for producing good software have been around for quite a while.
Sheesh, evil *and* a jerk. -- Jade
> 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
I used to be an avionics tech/computer system specialist for the US Navy. I specialized on the AYK-10 mission computer. During the years, I worked on/flew in the S-3B Viking. Due to the ancient technology of the AYK-10, we often did not even boot it until we were in flight. The magnetic drum did not like the carrier take-offs and often dumped if booted before flight. Rarely, did we have to reboot after the initial boot. Flight control was not affected by this. Neither was basic NAV/Weather radar or comms. As for ada, DoD is big on it. When I asked about it in the AYK-10 school, they told me it was because it was small and clean. I'm not sure that I agree with them, but since I don't know ada, I'll have to take their word. I'm guessing that the mission computer is based off of 80's technology as that would be par for DoD standards. At least it's pre-windows era. :)
Because for mission critical applications the US Department of Defence consider C, C++ and Java to suck.
See here for a brief history about why the US Department of Defence found that they were using 450 odd languages and needed to standardise on one common one that did everything right.
They produced a specification of what the language should do and found that nothing out there did what was required well enough. So a competition was born and ADA was the language that won it.
Avantslash - View Slashdot cleanly on your mobile phone.
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"...)
I will certainly grant that Win2k is a significant improvement, and perhaps an order of magnitude more reliable than NT4. I don't generally count Win98 in these comparisons; even very few slashdot trolls will stand up and try to make a go of claiming Win9x/Me exhibits reliability of any kind.
However, to put it in perspective, doing normal development with Java, VBScript, IIS, MS SQL Server, MySQL, Flash (I am deliberately excluding crashes that occured while coding C/C++ and other "non-safe" systems), I observe Win2k either bluescreening, spontaneously rebooting, or getting to a state where it needs to be power-cycled approximately 2-4 times a month. This seems like heaven compared to NT4, which I I used to crash daily while doing Java development and writing ASP pages for IIS. Most NT4 production servers I am aware of are rebooted regularly, often nightly, to prevent them from falling apart altogether. My experience with NT4 has been unequivocal. Don't use it in production unless you want to suffer.
That's not counting Win2k's constant explorer crashes, which are generally not disruptive but still a bit unsettling. The majority of the problem appears to come from Microsoft being unable or unwiling to sanitize the GUI code and protect failures to handle the GUI layer correctly from killing the entire system. That, and I still see the standard device-related problems. Burning CDs and attaching new mice have both proved catastrophic for Win2k, in the latter case requiring a complete reinstall of the operating system. No, I didn't build the mouse myself; it was a Logitech mouse.
I also note that, as with all other versions of Windows, Win2k still has a tendency to "decay;" that is, to continually develop small but uncorrectable problems until reinstall is eventually required. However, the decay rate also seems to have been slowed.
Compare this to Linux, which I also give daily and roughly equivalent use, and which _never_ crashes. _Ever_. In fact AFAIR the last time I had to deal with unexpected shutdowns on Linux was due to a foolish attempt to build a complicated high-speed SCSI chain a year or two ago. I am not aware of any problems on Linux which cannot be corrected without a reinstall of the OS, but perhaps there are exceptions in the crowd who can share experiences.
So... Win2k. Finally usable. But still not competitive.
To all knee-jerk anti-MS-criticism-on-slashdot and pro-MS trolls... if you're just skimming, now is the part where you hit reply and do your thing.
We're on the road to Tycho.
Any plane flying that has a computer system on it has the ability to do a hard boot of its systems. Often these happen automatically with watchdog timers, but most have a manual reboot. Keep in mind that for hte most part this is solid state stuff, so system reboots are a couple of seconds tops. Also, just about every system has at least a temporay backup to keep things running while the main system is rebooting.
An example is the F18 Super Hornet. Correctly we're working on have the ability to drive the HUD display from the fuel control computer. It needs to be able to drive it for 7 seconds, which is the amount of time it takes for the primary and secondary HUD systems to reboot.
Say what you want about the military, one thing they do when it comes to their planes is provide backup systems. You can fly a C130 using hand cranks in the fuselage to control the avionics (couple hundred cranks to fully elevate the flaps).
I haven't worked on the F-22, but I coded the Korean T50's OS and a new Navy IRaD FADEC.
At anyrate, the OS's aren't OTS, but designed and coded for each plane (Ada for all the military boxes). As for reboot, if the system becomes hosed, for any number of reasons, the Avionics will reboot. This is true in all aircraft, even your passenger planes.
They key thing to remember is that all of these systems are atleast dual redundant, meaning that the entire system doesn't reboot, just one channel. When that channel does reboot, the reboot is done in less than 200ms. (Usually faster).
This isn't like Windows where a reboot can take minutes, and you'll blue screen when it's finally running anyway. These are unique, tried and tested OS's, which operates with a Probability of Loss of Control around 0.3%
== Eagles may soar, but weasels don't get sucked into jet engines.
Why Ada?
Because quite a few years ago when all source code was Assembly, the US sponsored a Compile-off between high-level languages. The idea was that they'd adopt a single language and build compilers for it suitable for the thousands of different processors we use in all of the various systems around the world.
So Ada won, even though it was developed by a French consulting firm. Even now we maintain an Ada compiler for every single CPU type in existence. In fact, this is why Oracle's PL/SQL code looks so much like Ada. When Oracle was looking to make a PL for their database, a few gov't guys said: "Hey, why don't you make it like Ada. We'll buy it and our programmers won't have a high learning curve to tackle."
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.
Hello! It appears you are trying to fire a missile, would you like my assistance?