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.
Also, can anyone confirm if OSA is the name of the referenced ADA software project (1.7 million lines etc...)
Gmanske.
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.
Priority inversion is never caused by the OS, only by the interrupt/task priority design. So VxWorks shouldn't be blamed here.
There are RTOS'es that try to avoid priority inversion by temporarily raising the priority of the blocking task to the same priority as the task being blocked. This may at first look like a good solution but if the priority bumping happens too often, "medium priority" tasks may get starved because the low priority task is really running at high priority.
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.
Blocking interrupts may mean missing interrupts. This is a very dangerous thing to do in hard realtime systems, because what you don't know may not only hurt you but may actually kill you. If it is necessary to disable interrupts to get the system running, the system design is horribly flawed.
My opinion? See above.
> 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
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.
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."