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
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
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!
The flight controls are run by totally different hardware. It's the sensor and weapons systems that are at issue here.
Typically, when aero geeks talk about avionics, we're not talking about the flight control systems, even though those systems are now "aviation electronics".
Is this bad? Yes. Does it need to be fixed? You betcha. But don't worry about the planes not being able to keep the pointy end into the wind. That part seems to be working fine.
As an aside, the little anecdote about the test pilot intentionally making RADICAL configuration changes in-flight (moving fuel around, opening weapon bay doors, and wacky control inputs) producing only an easily-recoverable spin is a testament to the airplane's superb design. I mean, you do stupid things in ANY airplane and it'll bite you. The sign of a really GOOD airplane is that it then forgives you and doesn't splatter you all over the terrain.
Why yes, I AM a rocket scientist!
You sure about that? A stall is a condition in which the airflow over the wing becomes turbulent and separates from the upper surface of the wing. That destroys lift until the smooth airflow is restored.
To say that the F-22 is in a controlled stall is just ridiculous. The proper way to state things is that the F-22 has relaxed static stability, which has nothing to do with a stall.
If tits were wings it'd be flying around.
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.
If it requires an inflight reboot, there's no doubt what OS it's running.
RH support: Thanks for calling Red Hat! How may we help you?
Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'kernel panic' in white text on a black background."
RH Support: "And what is the system model?"
Pilot: "The the F-22 jet.."
RH support: If you read linux-kernel-bugtraq, you will see that you should have patched your kernel to 2.4.19-pre-alpha-revision-d before takeoff. But no problem, this is Linux after all. Do you have another F22 on your LAN? Just telnet in from there, su to root and restart sendmail.
Pilot: @#$*! Redhat! I'm switching to Debian if I survive!
RH support: Can I interest you in any RHAT?
telnet? on a wlan? better use ipsec, or the enemy will have your f-22's passwords in no time.
F-22 HUD Display: "Your System has been 0wned."
Oops.
> 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
> Sorry, but if you have to reboot the ENTIRE
.--.
:>
:>
:>
> avionics system of a F-22 you're fucked to say
> mildly.
Avionics and flight control systems are separate
and extremely disparate.
> This plane is always in a controlled stall,
That is extremely unlikely. A stall is defined as
a condition when the wing exceeds the critical
angle of attack (Which is in turn defined as the
angle of attack where the airfoil is no longer
producing lift, but is instead experiencing
separated and turbulent airflow).
|
| / \
Cl | /
1| /
| /
| /
| /
|/
+--------------
0 5 10 15 20
AOA (Degrees)
Is a typical graph depicting Cl (Coefficient of
Lift) and its relation to Angle of Attack. Lift
(And induced drag) increases with an increase of
angle of attack or an increase in speed.
Angle of Attack, for your reference, is defined as
the angle between the chord line and the relative
wind. The chord line of an airfoil is an imaginary
line connecting its leading edge with its trailing
edge.
The 'Relative wind' is defined as the flight path
of the aircraft.
Therefore, for an airplane to be flown perpetually
in a state of controlled stall, its airfoil would
always be pitched up at approximately 17 degrees
relative to the flight path of the airplane.
Would be quite funny to watch, actually.
There's a lot of misunderstanding about 'stalls'
out there. What the F-22 may be able to do better
than more 'conventional' airplanes, and perhaps
that to which you refer, is ride the edge of an
impending stall (In a high speed, hard banked,
high-G turn, for example) without diverging from
controlled flight.
I for one don't care for fly-by-wire. Perhaps I'm
old fashioned.
I'd rather the airplane do what I told it to do
than what it thinks I should have told it to do.
Same reason I like Unix- I don't want my airplane,
or my computer, doing what it thinks I meant
rather than what I told it.
-Kysh
--=:: Wings and tail and snout and scales of blackest night
> 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
pilot@airoplane:~$ su -c "apt-get install ejection-seat"
Password:
Reading Package Lists... Done
Building Dependency Tree... Done
E: Couldn't find package ejection-seat
Damn!
- If it requires an inflight reboot, there's no doubt what OS it's running.
Apple support: Thanks for calling Apple! How may we help you?Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'unresolved kernel trap' in white text on a black background, admittedly overlaid on very a friendly GUI. Before that, there was a three second delay accompanied by a busy icon whenever I tried anything."
Apple Support: "And what is the system model?"
Pilot: "The the F-22 jet.."
Apple support: Oh, sorry, we don't plan to support that hardware until version 10.3. Can you use 10.2 Jaguar until then?
Pilot: @#$*! Mac! I'm switching to BeOS if I survive!
Apple support: Can I interest you in a
If you were blocking sigs, you wouldn't have to read this.
I for one don't care for fly-by-wire. Perhaps I'm old fashioned
:)
Well, sure... except that for modern fighter aircraft that's simply not viable. What the original poster was trying to say was that the F-22 is not inherently stable in flight (the AE's out there will now point out how minutely incorrect that statement is). If the flight control software goes wacky, you will be unable to fly the plane -- even if it was good ol hydralics and pneumatics.
The F-22, like a lot of newer jets, has totally integrated flight systems. The ailerons do not work seperately from other control surfaces, particularly the directed thrust system. A human trying to control all of this at once would be overwhelmed, and have considerably lower flight capabilities than a fly-by-wire system.
Another poster pointed out the pilot intenionally doing bad things to the aircraft - shifting all the fuel to one side, opening the weapon bay doors on that side, etc. which threw the jet into cartwheels at 45k feet. Once the pilot released the controls the jet self-stabilized. That's pretty damn impressive. Ok, sure, with fly-by-wire you're pretty well hosed if it doesn't do this because you don't have a "real" concept of what the plane is doing and reacting.
Fly-by-wire is becoming standard on large commercial jets too. I suspect it'll be a long time before it's common place on your small, private plane though -- especially since I can't imagine a single engine prop ever being designed to be "inherently unstable" in the air
One of the most impressive things I've seen a Raptor do so far (on Discovery Wings, of course, heh) is fly backwards... jet is flying straight and level, pilot pulls the throttle all the way up and the jet actually goes into a "controlled stall" and moves backwards (or so it appears visually) for a short distance. Hell if I know if it's useful in combat -- but nifty to the layperson.
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."
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!
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.