Catch up on stories from the past week (and beyond) at the Slashdot story archive

 


Forgot your password?
Close
typodupeerror
×
Technology

F-22 Avionics Require Inflight Reboot 587

Posted by chrisd from the ctrl-alt-boom dept.
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."
This discussion has been archived. No new comments can be posted.

F-22 Avionics Require Inflight Reboot More

F-22 Avionics Require Inflight Reboot

Comments Filter:
  • Long ago a friend of mine was working on an add-in computer driven compass for the F-16 for a big defense contractor. She called me up looking for graphics algorithms (she was the junior engineer on the project). She was fighting with her boss who wanted to install an FPU to speed up their circle drawing routine (this drew the compass rose onto the screen) while she thought they could speed it up by switching algorithms. Why did her boss want an FPU - well, because software sine and cosine routines were too slow. (BTW, the circle was always the same size and just the tick marks actually moved).
    • Please tell me you told her about Bresenham's integer circle drawing algorithmn...

    • How I solved this for a heads up display - 15 ya (Score:5, Insightful)

      by jerryasher ( 151512 ) on Monday July 22, 2002 @02:31AM (#3928861)
      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!

    • Re:Why a reboot - because the creators are bozos (Score:5, Interesting)

      by TheStruuus ( 263229 ) on Monday July 22, 2002 @11:35AM (#3930894) Homepage
      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.

  • Finally! (Score:3, Funny)

    by decaying ( 227107 ) on Monday July 22, 2002 @02:14AM (#3928807) Homepage Journal

    My years of Comp Sci with Ada as the language of choice (Uni's not mine).... I struggled with it, and grew to hate it.....

    At least I know who uses the bloody thing.... The tutors never could.....

    • Re:Finally! (Score:3, Insightful)

      by Jeppe Salvesen ( 101622 )
      Ada is excellent for this sort of stuff. It's been designed for implementing anal designs. That is exactly what is required in military systems.

      I also thought Ada is a good language for teaching in Uni. You don't like it, but it will teach you a lot of important concepts, from its strong typing amongst other things.

      That being said, it's not the right tool for most software development being done currently.

  • Boeing's Avionics press release (Score:5, Informative)

    by Perdo ( 151843 ) on Monday July 22, 2002 @02:14AM (#3928809) Homepage Journal
    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.

    • According to what this says, the avionics package meets or exceeds expectations. Now, this is not an MS bash, but I can recall of the top of my head that our intelligence services have database software that can only search on one term that probably met or exceeded expectations, and there's that ship that had to be towed back to port due to some NT failures.

      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. I wonder if people who sit at desks and write specs all day for military projects decided that only having to reboot now and then exceeds expectations as set by people not flying in the aircraft.

      I'll probably get modded down, but I just think this sort of thing (Boeing's press release, the actual performance as reported, and the overall state of technology in our government) is a bit troubling and it doesn't appear to be getting better.

      • Re:Boeing's Avionics press release (Score:4, Interesting)

        by Anonvmous Coward ( 589068 ) on Monday July 22, 2002 @02:57AM (#3928921)
        "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.
        • Those who would criticise you must be pretty stupid. You simply tell your experience with win2k. I have found it to be a very stable OS as well, and any problems have more usually been a case of bad hardware/drivers in my experience.

          Windows XP has also been really stable for me (and others). I have 10 days of uptime right now, without a problem. I only reboot for updates, and I do that at convienient times. The server 10 feet away only boots when need to fiddle with its hardware (behind a firewall after all). Win2k is just as stable as the two debian machines besides it.

          Stop thinking that all windowses are as stable as Win9x, it is just not true. It would be like saying MacOS X is crashing all the time because MacOS 7.x did. Lying after all doesn't give good arguments in the long run. Let it be sufficient to say that Linux is stable and leave it at that, don't make such a point out of it being more stable than Win9x, nobody is speaking about how well Linux 1.2 does these days do they?

          That said, I just installed Gentoo 1.3b at home, all the other distros are now 0wned;)
        • 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.

          So, when's the last time youve applied patches on that box? 3 months uptime means you are missing at least 1 major IIS patch that plugs a hole that allows an attacker to run arbitrary code.
        • 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.

          Up to the job...well, as a desktop OS for a typical business, I'll agree with you. For an avionics platform, though, I'd be afraid to be on the plane until it had been in use for 3-4 years and proven itself safe.

        • Windows... better, but still not competitive (Score:4, Insightful)

          by DaveWood ( 101146 ) on Monday July 22, 2002 @07:43AM (#3929451) Homepage
          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.

  • Please reboot... (Score:5, Funny)

    by Subcarrier ( 262294 ) on Monday July 22, 2002 @02:15AM (#3928812)
    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.

  • Duh.. (Score:4, Funny)

    by Malduin ( 207683 ) <<moc.eeknumbew> <ta> <etamirp_lautriv>> on Monday July 22, 2002 @02:15AM (#3928813) Homepage
    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!"

    • Re:Duh.. (Score:5, Funny)

      by sql*kitten ( 1359 ) on Monday July 22, 2002 @03:09AM (#3928940)
      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?

      • Re:Duh.. (Score:5, Funny)

        by Bartmoss ( 16109 ) on Monday July 22, 2002 @03:54AM (#3929009) Homepage Journal
        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.

      • Re:Duh.. (Score:4, Funny)

        by Grey Brick ( 311029 ) on Monday July 22, 2002 @05:35AM (#3929190) Homepage
        If it requires an inflight reboot, there's no doubt what OS it's running.

        FreeBSD support: Thanks for calling FreeBSD! How may we help you?
        Pilot: "Uhh.. I'm spiraling towards the earth, both my engines are out, and my display says 'Fatal trap 12: page fault while in kernel mode' in white text on a black background."
        FreeBSD Support: "And what is the system model?"
        Pilot: "The the F-22 jet.."
        FreeBSD support: No worries, just send us a full backtrace... you _did_ enable debugging information in your kernel didn't you?!
        Pilot: @#$*! FreeBSD! I'm switching to OpenBSD if I survive!
        FreeBSD support: RTFM!

      • Re:Duh.. (Score:5, Funny)

        by GroovBird ( 209391 ) on Monday July 22, 2002 @05:45AM (#3929204) Homepage Journal
        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!

        • pilot@airplane:~$ su -c "apt-get install ejection-seat"
          Reading Package Lists... Done
          Building Dependency Tree... Done
          Package ejection seat is a virtual package provided by:
          ejection-seat-gnome
          ejection-seat-gnome2
          kseat
          gtk-seat++
          qteject-o-matic
          ncurses-eject
          ejection-svga

          ...all requiring about 31MB of dependency downloads (or 187MB for ejection-seat-gnome2, which may break 'parachute-gnome') over your 9600bps link.

      • Re:Duh.. (Score:5, Funny)

        by Rogerborg ( 306625 ) on Monday July 22, 2002 @06:44AM (#3929297) Homepage
        • 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' [arstechnica.com] 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 [aviationartprints.com] until then?
        Pilot: @#$*! Mac! I'm switching to BeOS if I survive!
        Apple support: Can I interest you in a .Mac subscription?

    • Re:Duh.. (Score:3, Funny)

      by gilroy ( 155262 )
      Almost. But of course, if they don't admit the problem, it's not a "known issue". The conversation would be more like:

      Microsoft: Oh yes, there are known issues with that system. We should have a hot update in, say, two to six months. Until then, we suggest the workaround of never leaving the ground.
      Pilot: But it's a fratzing PLANE!
      Microsoft: If you care to read your End User License Agreement, you will see that Microsoft makes no warranty as to the usefulness of the software for any given task, including that for which it was purchased.
      Pilot: This is a $500M plane you're responsible for.
      Microsoft: Actually, if you read the EULA, Microsoft is not responsible for any damages caused by failure of the software, whether or not those failures were known, or avoidable, or intentional.
      Pilot: That's it. I'm ejecting.
      Microsoft: Actually, sir, the maker of the ejection seats chose not to use WindowsXP embedded. To preserve the integrity of the Windows experience, your on-board avionics have been instructed not to interoperate with the rogue OS on the ejection seat. But WindowsEJ will be out in first quarter 2003 for your ejection seat pleasure.
  • The requirements for the F-22's avionics system are derived from the F-22 Weapon System Concept, the guiding design principles for the aircraft's overall design. The integrated avionics system is one of the essential elements, along with stealth, maneuverability and supercruise, which will give the F-22 the tactical advantage against the threats of the future.

    The F-22's avionics suite features extensive use of very high-speed integrated circuit technology, common modules and high-speed data buses. The avionics suite is an advanced integrated system that allows the pilot to concentrate fully on the mission, rather than on managing the sensors.

    The avionics system is now flying on the F-22, and the advanced Block 3.0 software, which provides nearly full sensor and avionics functionality, began testing on the Raptor in early 2001.

    Technologies incorporated in the F-22 include:

    A common integrated processor (CIP), a central "brain" with the equivalent computing throughput of two Cray supercomputers

    Shared low-observable antennas

    Ada software

    Expert systems

    Advanced data fusion cockpit displays

    Integrated electronic warfare system (INEWS) technology

    Integrated communications, navigation and identification (CNI) avionics technology

    Fiber optic data transmission.

  • F-22 "avionics" (Score:4, Interesting)

    by sluggie ( 85265 ) on Monday July 22, 2002 @02:21AM (#3928832)
    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!

    • Re:F-22 "avionics" (Score:5, Informative)

      by Moofie ( 22272 ) <lee@ringofsaturn . c om> on Monday July 22, 2002 @02:39AM (#3928878) Homepage
      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.
      • The sign of a really GOOD airplane is that it then forgives you and doesn't splatter you all over the terrain.

        Good! Now MSCEs can defend the US in the IT and military fieldsby simply attending a 3 day intensive training seminar. As an expected bonus I can mention the HUGE savings in TOD. Oh god, the gift that keeps giving! :)

        (TOD = Total Cost of Defense)

    • Re:F-22 "avionics" (Score:5, Informative)

      by PD ( 9577 ) <slashdotlinux@pdrap.org> on Monday July 22, 2002 @02:41AM (#3928882) Homepage Journal
      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.
      • Alright I'm sorry, since english is not my native language I ceased to get the right definition of stall.

        What I meant to say was that the CPU always has to do litle rudder movements to prevent it from falling down, or the other way round: the pilot wouldn't be able to keep the plane up with his stick alone.

        And yeah, I know there's some subliminal punchline in "keep the plane up with his stick" ;)

        • Not a "stall". A stall is where the plane flies too slow, the wings no longer produce enough lift to keep it in the air, and the thing basically just drops out of the sky.

          The processor doing its little movements just means that it's an unstable system. Nothing new there, the SR-71 also requires an active control system to keep it going in a straight line, and that was designed 20-some years ago.

          Grab.
      • have a look at this [gatech.edu]. i'm not saying the f22 does this, but the concept is not ridiculous!

      • Pictures of F-22 (Score:2, Informative)

        by LippyTheLip ( 582561 )
        Perhaps I am not the only slashdotter left who does not know what this thing looks like.

        You can find a selection of pictures here [af.mil]. The fourth and fifth rows from the botttom of the page have photos of the F-22. The best one is here [af.mil].

    • Re:F-22 "avionics" (Score:5, Informative)

      by Kysh ( 16242 ) on Monday July 22, 2002 @04:56AM (#3929139) Homepage Journal
      > 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

      • Re:F-22 "avionics" (Score:5, Interesting)

        by Zathrus ( 232140 ) on Monday July 22, 2002 @07:20AM (#3929376) Homepage
        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.
      • I for one don't care for fly-by-wire. Perhaps I'm
        old fashioned.         I'm not sure. Automation sometimes enable us to do things we could not otherwise do. You could not fly the F22 without the computers - it's much too unstable. However, if the F22 was more stable, it would not have the required flight characteristics in order to win the dogfight as often as it could.

        On the flipside, it's always good to be able to do as much as possible manually. When machines fail, we're fucked if we don't have any backup. I wouldn't be surprised if the terrorists at some point would attempt to teach us that.

        The need to understand the basics first may be why they still teach students how to fly in small, primitive single-engine planes.

        One last thing. Automation also levels the playing field a bit between the truly talented and the skilled. You like Unix because it gives you control. Most people dislike Unix because it gives them too much control - too few things are automated and beginner-friendly, and they don't know how to use their freedom. Hrmph. I sometimes wish the world was black and white, but it's much more challenging when it's all greys.

  • It's a safety feature. (Score:5, Funny)

    by Black Parrot ( 19622 ) on Monday July 22, 2002 @02:21AM (#3928833)

    Everyone knows that frequent reboots prevents crashes.

  • Similar to Mars Pathfinder (Score:5, Interesting)

    by Deton8 ( 522248 ) on Monday July 22, 2002 @02:22AM (#3928837)
    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.

    • Re:Similar to Mars Pathfinder (Score:5, Informative)

      by ebbe11 ( 121118 ) on Monday July 22, 2002 @02:53AM (#3928913)
      In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion.

      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.

    • There is an interesting account of that here: What Happened on Mars? [cmu.edu]

  • Re: Why do you need the inflight reboot? (Score:5, Funny)

    by back@slash ( 176564 ) on Monday July 22, 2002 @02:23AM (#3928838)
    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....

  • Redundant (Score:4, Interesting)

    by Perdo ( 151843 ) on Monday July 22, 2002 @02:27AM (#3928850) Homepage Journal
    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"

  • Contractor Breakdown for F-22 (Score:4, Informative)

    by gmanske ( 312125 ) on Monday July 22, 2002 @02:37AM (#3928873) Homepage
    For a good breakdown of who (LM, Boeing, others) supply what, have a look here [fas.org].

    Also, can anyone confirm if OSA is the name of the referenced ADA software project (1.7 million lines etc...)

    Gmanske.

  • imagine this (Score:5, Funny)

    by drDugan ( 219551 ) on Monday July 22, 2002 @02:42AM (#3928886) Homepage


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

  • Why do you need the inflight reboot?

    Because that is the nature of complex algorithmic systems. An algorithmic system is temporally inconsistent and unstable by nature. Using the algorithm as the basis of software construction is an ancient practice pioneered by Lady Ada Lovelace and Charles Babbage. It is the fundamental reason why dependable software systems are so hard to produce.

    There is something rotten at the core of software engineering. Software functionality should not be fundamentally different from hardware functionality. Software should emulate hardware and serve as an extension to it. It should only provide the two things that are lacking in hardware: flexibility and ease of modification. The only way to solve the reliability crisis is to abandon the bad practice of using algorithms as the basis of software construction and to adopt a pure signal-based paradigm. More details can be found at the links below:

    Project COSA [gte.net]
    • This isn't a joke. Read the linked pages, moderators. There is a rather large amount of thought and theory behind the ideas presented.

      Of course, any computer can be thought of as a signal processing device. It has input (the sequence of bits in the program code and data storage and external input (e.g., keyboard, mouse, network, etc)), state (memory, registers, etc), and output (display, sound card, printer ports, disk, network, etc).

    • Because that is the nature of complex algorithmic systems. An algorithmic system is temporally inconsistent and unstable by nature. Using the algorithm as the basis of software construction is an ancient practice pioneered by Lady Ada Lovelace and Charles Babbage. It is the fundamental reason why dependable software systems are so hard to produce.

      This reminds me of a story [slashdot.org] on Slashdot a few years ago about the process of writing the software that contols space shuttles. Still an interesting read.

      (As timothy writes: These guys are "pretty thorough" the way Vlad the Impaler was "a little unbalanced." I could have certainly sometimes saved a lot of time using similar bug-documenting stuff.)

    • Re:There Is Something Rotten in Software Engineeri (Score:5, Insightful)

      by Black Parrot ( 19622 ) on Monday July 22, 2002 @04:53AM (#3929129)

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

    • There is something rotten at the core of software engineering.

      Careful. If anything is rotten, it's the practice of trying to apply pure computer SCIENCE to practical machine control problems. Real engineers (who have a degree in engineering) tend to be much more pessimistic, self critical, and more driven to design the system before sitting down to write software. Reliable machine control software does get written on a regular basis, and much of it gets written in an algorithmic paradigm.

      Engineers who write good machine control software do several things to better their odds:
      1) KISS
      2) Stay away from dynamic memory structures when you can, otherwise use a language or environment that helps check for memory leaks, etc.
      3) Use a proven platform (i.e. a PLC, VLC, or a good RTOS like QNX).
      4) Design, write spike solutions, design, discuss, redesign, discuss, design again, write, test.

      Real software engineering may not be an edge of your seat, nailbiting, all night hacking experience, but it does tend to produce reliable, working results.
    • [sarcasm]
      Ok, I buy it. Now show me some Cosa that can emulate my Linux Kernel, my Galeon browser and my Mplayer media player (or another tool/application at your choice) so that I can see which one's best.
      [/sarcasm]

      Algorithms do not make programs fail. Bad logic makes them crash and be unstable. The HIGHER the language level, the lower the failure rate and the faster/cheaper the implementation is. I'd love to see an OS developed as in a DSP fashion :)

  • i960 in PC's (Score:2, Interesting)

    by Ratso Baggins ( 516757 )
    More than 10 years ago I first saw a i960 dev board, and I thought "YUM! I can't wait for PC's to use them..." But they haven't. Anyone have any valid conjecture as to why?
    • A good number of RAID controller cards used them, and have done for a while now. They are in PCs all over the world as we speak.
    • If I remember right, some of the first commercial RAID boards ("Dell Drive Array") used the i960.

      Can't think of anything else, though. The i860 and i960 were supposed to take over the planet at one point, but it never seemed to happen.
      • The i860 and i960 were supposed to take over the planet at one point, but it never seemed to happen.

        The earliest version of Windows NT was written on the i860. The i860 machine was called the N-10, that's where the NT in NT comes from (other theories are "New Technology" and "Northern Telecom", but the NT product manager says it's from N-10 and I believe him). I expect the decision to mainly target x86 was just due to the sheer installed base, there was never a compelling enough reason for Intel, IBM, MS et al to move away from it. These days the i960 is used for Raster Image Processing (RIPing) in laser printers.

  • Drivers? (Score:2, Funny)

    by zentu ( 584197 )
    So, uh when do they update the drivers for the displays, and when do they know that there was a problem with them? Pilot: Air traffic contol, come in. Air Triaffic contoler: We read you Pilot. What's your problem. P: The heads up display is going fuzzy, any clue what may be wrong?. ATC: Let me see, what version of the Windows F22 are you running? P: The version my machanic put in. ATC: So do you see the blinky red light in the left corner? P: No, I see a green one on the upper right. ATC: Well, you need to come back to base then, you have the old drivers. P: O.K. I will turn around now. ATC: Oh, by the way, the problem with your version is that the ground is actually off by six feet, becareful. P:WTF? Is it up or down? ATC: it varyies, by the driver version....

  • grrr (Score:2, Insightful)

    by yatest5 ( 455123 )
    If so, why do you need the inflight reboot?

    Is this how low slashdot has sunk? Someone can't be assed to research themselves the answer to a question so they post it to our x million readership?

    Or maybe it's just another shameless editor troll for reams and reams of the same tired old offtopic MS / Windows 98 / BSOD jokes?

    Jesus, is there any chance of getting any intelligent replies? I checked out kuro5shin recently and was surprised at how intelligent most of the posts are.

    Anyway, mod me down because I haven't slagged MS, whatever.

  • Unfortunately, they are using Ada (Score:3, Flamebait)

    by Florian Weimer ( 88405 ) <fw@deneb.enyo.de> on Monday July 22, 2002 @03:24AM (#3928964) Homepage
    Since they use Ada, this war machine will actually work, despite more 1.5 million lines of source code running it. That's sad, why couldn't they use C, C++ or even Java for such projects, where failure might actually benefit mankind?

    • Re:Unfortunately, they are using Ada (Score:4, Informative)

      by Mr_Silver ( 213637 ) on Monday July 22, 2002 @06:47AM (#3929303)
      That's sad, why couldn't they use C, C++ or even Java for such projects

      Because for mission critical applications the US Department of Defence consider C, C++ and Java to suck.

      See here [liv.ac.uk] 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.

    • Re:Unfortunately, they are using Ada (Score:5, Informative)

      by Stultsinator ( 160564 ) on Monday July 22, 2002 @08:53AM (#3929775)
      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."

  • I seem to remember hearing somewhere that the avionics system on the F-22 uses a neural net of some sort. In my experience, some kinds of neural networks can develop this creeping flakiness as a result of a sort of entropy in the weightings on each neuron. Since neural nets are subtle enough that it would be nigh-impossible to get rid of this cruft on the fly, the best way I can think of to fix problems is to simply reset all of the weights to a default value.

    The best analogy of this that I can think of is to say that it's similar to a reboot, even though it doesn't necessarily require shutting the entire system down for a period of time.

    Of course, like all hearsay, this doesn't make a whole lot of sense when you think of it. . . I'm not aware of any reason why they would put a neural net that continues to learn while it is being used in control of the avionics system, but then again a lot of technologies I see make no sense to me. . .
  • This is the only application I can think of where you reboot BEFORE you crash...

  • Alert, i have crashed please reboot

    __reboot__

    Last time you rebooted it was due to a crash ..

    • 1.reboot in safe mode(no missiles)
    • 2.reboot electronics only
    • 3.Reboot in parachute mode
    __parachute mode__

    Illegal instruction at address FFCFFFCC

    • 1. Start praying
    • 2. SEnd email to mom
    • 3. Wait
    __2__

    ould not connect to mail server

    • 1. retry
    • 2.Abort
    • __2__

    • Illegal instruction at address blah blah So you want to die:

      • 1. With fireworks on ground
      • 2. In ocean
      __2__

      I wont listen to you i a going to crahs now.. 4 5 3 2 1 . . . Failed to crash :-(

      and so the pilot walks home safely :-)

  • unfair reporting and out of context. (Score:5, Informative)

    by small_dick ( 127697 ) on Monday July 22, 2002 @04:41AM (#3929114)
    If you actually read the article, they blow off the reset as a minor bug to get past. The thing has been flying since 1990.

    Considering that the F-16 and F-15 designs are 25-30 years old, it might be a good thing to build something new.

    Thrust vectoring, stealth, supercruise...like the article says, it's not clear what kind of threats the USA will be facing in the future, but someday the F-22 will prove itself and astonish a lot of people.

    I think that's the main gist of the article, and picking the bit about a computer reset and making it sound like a big deal is right out of trash teevee.

    To me, the most important part was the test pilot in the F-22 giving his opponent in the F-15 a hard time...actually telling him over the radio where he was. F-15 still could not get a lock. This is great stuff.

    • Re:unfair reporting and out of context. (Score:4, Insightful)

      by thales ( 32660 ) on Monday July 22, 2002 @07:08AM (#3929345) Homepage Journal
      " If you actually read the article, they blow off the reset as a minor bug to get past. The thing has been flying since 1990."

      The article was a very postive look at the F22, however it was from the Atlanta Journal Constitution which has a long history of acting as a cheerleader for aircraft from Lockheed's Marietta plant which is located in Atlanta's suburbs. The F22 is a kick ass plane, but the Atlanta newspapers are not an objective source of information for any problems the project may be having. They proved this many times by glossing over problems with the C5. (built at the same plant)

  • Can we say classified? (Score:4, Funny)

    by AIXadmin ( 10544 ) on Monday July 22, 2002 @04:53AM (#3929130) Homepage
    "Any Slashdotters working on this project? If so, why do you need the inflight reboot?"
    Yes lets find someone to discuss the internals of what is undoubtedly classified material.

    I can just see it:
    "Man executed for posting on Slashdot."

  • Eurofighter (Score:4, Funny)

    by Nexus Seven ( 112882 ) on Monday July 22, 2002 @04:55AM (#3929137)
    I read somewhere that when the computer on board the Eurofighter 2000 fails, the aircraft attempts to reboot it.

    If it cannot reboot on the seventh attempt, the aircraft automatically ejects the pilot.

    As each reboot attempt takes milliseconds, you could be flying happily along only to suddenly find yourself being catapulted into the air.

  • Any Slashdotters working on this project? (Score:3, Funny)

    by echucker ( 570962 ) on Monday July 22, 2002 @05:30AM (#3929182) Homepage
    Even if they were, do you think they could tell the rest of us?

    Doubt it.

  • In my past experiences... (Score:4, Informative)

    by TrAvELAr ( 118445 ) on Monday July 22, 2002 @06:07AM (#3929230)
    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. :)
    • I'm not sure Ada is small and clean either, and I had 4 years of it at Auburn University since that was the required language for data structures and algorithms classes. They alleged that Ada was bullet proof as a language...that it never crashed, dumped core, etc., so made perfect sense for use in avionics. Mind, we were getting government contracts, so it's entirely possible that they were spouting the party line.

      At any rate, my observations are as follow: First, the Ada syntax was based on the Pascal syntax (they state this in the textbooks). Second, it is almost as anal as Java. Third, you may write a program in Ada but if you use Gnat to generate your code, it's getting translated to C anyway, so theoretically your bullet proof code just developed some vulnerabilities.

      I guess Ada has its uses, but I heard recently that even the DoD has stopped requiring its use.

      • Re:In my past experiences... (Score:4, Informative)

        by Amazing Quantum Man ( 458715 ) on Monday July 22, 2002 @09:04AM (#3929842) Homepage
        At any rate, my observations are as follow: First, the Ada syntax was based on the Pascal syntax (they state this in the textbooks). Second, it is almost as anal as Java. Third, you may write a program in Ada but if you use Gnat to generate your code, it's getting translated to C anyway, so theoretically your bullet proof code just developed some vulnerabilities.

        1. What do you mean *ALMOST* as anal? It's more anal.

        2. You won't be using GNAT in an avionics systems. You'd be using a Validated platform. That means that the compiler, OS, *AND* target platform have been validated together. It costs a bundle.

        3. DoD has removed the mandate that ALL new software be written in Ada, but most avionics are written that way for safety reasons (editorial: Ada83 sucked, but Ada95 is a fairly decent language).
      • I'm not sure Ada is small and clean either

        Ada wasn't designed to be small and clean. It was designed as a 'catchall' language, able to do everything from low level system programming - replacing assembler & C to the highest possible level application program. You can't really make a small & clean language, and hit both ends of this spectrum. On top of that, it was realized that a lot of the 'bugs' in programs are preventable, because they are caused by the programmer not properly handling error conditions. So they added in features which make it harder for the programmer to screw up. Together, this means that Ada is a very large language compared to other languages of the 70's, however you don't have to know all of Ada to write a program, especially if you're only working in one problem domain.

        As for the requirement, as of 1994, is that Commerical off the Shelf (COTS) is the prefered choice, whenever it meets their needs. Failing that, Ada is required, but waviers can be granted if they are cost effictive, and that the proposed alternative does not compromise the goals of the project - in particular the safe programming practices that Ada requires.

  • This is nothing new, or overly scary (Score:5, Informative)

    by sunking2 ( 521698 ) on Monday July 22, 2002 @08:24AM (#3929598)
    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).

  • Avionic OS's and Reboots. (Score:5, Informative)

    by DracoPyre ( 208046 ) <jasonasmith@noSPam.yahoo.com> on Monday July 22, 2002 @08:41AM (#3929696) Homepage
    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%

  • The risks of fly-by-wire: Crash Video (Score:3, Informative)

    by LunarFox ( 591499 ) on Monday July 22, 2002 @08:42AM (#3929700)

    In 1988, a brand-new Air France Airbus A320 crashed into trees during maneuver at an airshow in France. The aircraft failed to gain height during a low-altitude pass with the landing gear extended. Three of the 136 passengers were killed.

    The A320 was the first civilian aircraft to use fly-by-wire, which replaces conventional stick and rudder control with 3 computers and miles of electronic cables. The pilot uses a game-like joystick to his side.

    Some good video of this accident is available here [wox.org], among other places.

    Ultimately, the pilot was blamed (when in doubt, claim human error). But you have to wonder what role the computer played in this crash, even if it simply confused the pilots or acted differently than they expected. Apparently, this wasn't the only A320 crash where its flight control system was suspected, either.

    It's interesting to note that Airbus has a different design philosophy vis-à-vis fly-by-wire: they believe the computer should restrict the pilots from putting any undue stresses on the airframe, or doing anything that the system thinks is "unsafe". This is contrary to Boeing, who program their computers to allow even the most dangerous manuever, with the intention of giving the pilots ultimate control over the aircraft.

  • Embedded World (Score:3, Insightful)

    by drxenos ( 573895 ) on Monday July 22, 2002 @09:10AM (#3929875)
    You can tell from the comments the number of people who never worked in the embedded world. You can not apply PC design methodologies to an embedded system. In the embedded world, the software must be fault tolerant. If must not lock-up; if must always reboot. Embedded Engineers know and except that ALL software has bugs and ALL software will eventually crash. In the event of a crash, the computer must never lockup; it must recover. And while its recovering, a backup computer must take over until the primary computer is up and running again. As for Ada, you write just as crappy code as you can in any other language. As strongly typed as Ada is, it will not save you from yourself. A bad programmer is just as bad in Ada, as he would be in C. Worse, when that bad programmer forces Ada to use "pointers," they will always be functionally equivilent to void* and contain no type information at all. Why would he do this? For the same reason his code is littered with "use at," he is a bad programmer.

  • Slight difference - These reboots are much faster (Score:3, Informative)

    by deranged unix nut ( 20524 ) on Monday July 22, 2002 @09:36AM (#3930017) Homepage
    I went to a talk recently where a researcher was explaining human factors applied to military jet aircraft. The explanation that he gave of reboots in these systems was a 1/10th of a second or less pause - the pilot pushes a button to say "No, the computer has it wrong, it is giving me a different display than I need, reboot and give me the default display again."

    A "personal" computer reboot takes > 30 seconds nd would be unacceptable. These reboots are near instantanious.

    (I could be wrong, maybe this is a different aircraft and a different type of reboot than the researcher was talking about.)

Slashdot Top Deals

If you steal from one author it's plagiarism; if you steal from many it's research. -- Wilson Mizner

Close