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

Comments

Finally!

[decaying]

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!

[Jeppe Salvesen]

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

[Perdo]

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.

Re:Boeing's Avionics press release

[philipsblows]

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

[Anonvmous Coward]

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

Please reboot...

[Subcarrier]

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

[Malduin]

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

[sql*kitten]

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

[Bartmoss]

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

[Grey Brick]

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

[GroovBird]

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!

Re:Duh..

[Rogerborg]

• 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 .Mac subscription?

Re:Duh..

[gilroy]

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.

F-22 "avionics"

[sluggie]

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"

[Moofie]

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.

Re:F-22 "avionics"

[PD]

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.

Re:F-22 "avionics"

[Kysh]

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

[Dun Malg]

20? try 40. It was first fielded during the johnson administration.

Re:F-22 "avionics"

[Zathrus]

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.

It's a safety feature.

[Black Parrot]

Everyone knows that frequent reboots prevents crashes.

Similar to Mars Pathfinder

[Deton8]

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

[ebbe11]

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.

Re: Why do you need the inflight reboot?

[back@slash]

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

[Perdo]

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"

Re: Drivers?

[Black Parrot]

> Stonent Imagine a Beowulf cluster of whatever this story is about!

They already thought of that. You see, while they rarely mention it at air shows, the realy reason airplanes fly in formation is because those "formations" are actually high-availability clusters for their avionics software.

How I solved this for a heads up display - 15 ya

[jerryasher]

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!

Contractor Breakdown for F-22

[gmanske]

For a good breakdown of who (LM, Boeing, others) supply what, have a look here.

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

Gmanske.

imagine this

[drDugan]

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

Re:I had to say it...

[Anonvmous Coward]

Not to be cliche or anything, and I'm sure you could see this one coming a million miles away,

but what happens when it crashes?

Hahahahaha!!!

This reminds me of some trouble I got into in high-school once: Anybody remember Channel 1? It started around 1990-1, and it was a news channel that some schools got. Each episode had a trivia question just before a commercial break.

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.

Re:F-22 BSOD...

[Anonymous Coward]

I wonder if there are Ctrl, Alt, and Del buttons on the F-22 cockpit console?

Sure, Ctrl is on the right control panel, Alt on the left, and Delete on the stick. :-)

Unfortunately, they are using Ada

[Florian Weimer]

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

[Mr_Silver]

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

[Stultsinator]

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

Re:There Is Something Rotten in Software Engineeri

[Black Parrot]

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

Re:Ada ?

[Kysh]

> 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

In my past experiences...

[TrAvELAr]

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

Re:In my past experiences...

[shaldannon]

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

[Amazing Quantum Man]

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

Re:In my past experiences...

[gorilla]

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.

Re:There Is Something Rotten in Software Engineeri

[joib]

When that attitude changes we'll start seeing software that rivals hardware in reliability..

Or will we start seeing bridges collapse as an everyday occurance? :) Well, hopefully not.

Re:Ada ?

[Jamie Zawinski]

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.

In what way is Ada better than Java in this respect? I only know a little about Ada, so this is a serious question. My understanding is that Ada and Java have very similar safety goals (especially with respect to exceptions) so I'm curious about what you think Ada gets right and Java gets wrong.

It should be the case that the only way for a Java program to "crash" is if there is a bug in the runtime library or hardware interface: the same kinds of problems can of course affect Ada.

(I've got a lot of problems with Java, mind you, but I'd never say it was "too lenient"...)

Re:Ada ?

[Kysh]

> In what way is Ada better than Java in this
> respect? I only know a little about Ada, so this
> is a serious question. My understanding is that
> Ada and Java have very similar safety goals
> (especially with respect to exceptions) so I'm
> curious about what you think Ada gets right and
> Java gets wrong.

Let me be fair.. as a language, I'm not terribly
familiar with java. I have spent a great amount of
time supporting Java developers on the system
level, however. I have seen developers write java
code that crashes in very gnarly ways, and had to
support them. I've seen java interpreters just
spontaneously die. Now this could certainly be
buggy implementations, and not a bad language
specification. While that was not the impression I
was given by the developers in question, I don't
deny the possibility. I have, personally, never
seen an Ada program 'crash'. I have never seen an
Ada program exit in any way other than an
unhandled exception or a normal exit. I've seen
Java do a lot worse.

I will not say that java, as a specification, is
less 'safety critical' than Ada, only that I am
not aware that it is as much so. If the
implementation is the problem, as I mentioned that
it could be above, then pending better
implementations, I'll check back in with this
topic. :>

In closing, though, I have to say that, from the
information I have, an Ada program is about a
billion times more reliable than a Java program,
when you're talking about large (Or huge)
applications. Ada also has the benefit of a big
experience base, mathematical analysis, review,
etc.

I'm open to comments regarding Java
implementations, stability, and the
safety-critical methodologies present (Or lacking)
in Java from those more familiar with the
language.

Respectfully,

-Kysh

Re:There Is Something Rotten in Software Engineeri

[fferreres]

[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 :)

Windows... better, but still not competitive

[DaveWood]

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.

Re:Ada ?

[shaldannon]

I had the (dis?)pleasure of learning Ada as the required language in 4 years at Auburn University's Computer Science department. While what you say is quite true (from my observation) my two biggest objections to it were verbosity and strong typing. It's really, really annoying to have to convert, say, and int to a float through a function call. I'm not even asking for a Perl-style eval{} here...I just want the ability to declare something as an int with value 3, divide it in half, and reassign the value back so it is now a float 1.5....I also want the ability to get a newline without having to type in 'Newline;' or 'Ada.Text_IO.Newline;'. For what it's worth.

Until that time...I write Perl code all day long in web apps (nobody dies if your web app goes kaput).

This is nothing new, or overly scary

[sunking2]

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

Re:Ada ?

[SuiteSisterMary]

I just want the ability to declare something as an int with value 3, divide it in half, and reassign the value back so it is now a float 1.5

Holy CRAP.

Avionic OS's and Reboots.

[DracoPyre]

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

[LunarFox]

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

Re:F-22 BSOD...

[stilwebm]

You have to find a paperclip, the straighten one end to fit it in the small "reset" hole on the side of the console.

Embedded World

[drxenos]

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.

Re:Why C?

[Erich]

People act as though C and C++ are the top of the language evolutionary scale--sheer nonsense. C and all of the "C-alikes" have held back decent software engineering now for decades...we get to enjoy buffer and stack overflows, pointers wandering through address space and other idiocies.

You act as though C is responsible for a stack overflow or pointer pointing problems.

You wanna know something: IT'S THE PROGRAMMER.

You can write huge applicatations in plain ANSI C. They can run flawlessly. As long as you use good programming practices and have good programmers.

Excepting buggy compilers or libraries (very rare in my experience), when you write something in C and it doesn't work, it's your fault. C is very simple, elegant, and deterministic. For examples of C programs that work very well, see UNIX OS kernels, most of the system tools on UNIX, and especially TeX.

You can write perfect programs in some "more modern" languages ("safe" languages like Java) that will crash, because the environment is so complex that many environments are buggy. This is unacceptable. Not only that, most of these languages aren't any better than C as far as memory management (That's why all the Java programs I see crash with "NullPointerException").

These new languages, however, do increase the overhead of a program running, to make things slower. As a computer engineer, I do like that feature, as it means that people will go out to buy more complex hardware.

There are some programming languages that really do have features that help write very very stable, unbuggy code. I would say ADA, ML, and LISP fall in these catagories. But even in these languages, the language can only do so much. In the end, your program will only be as good as your programmer.

We STILL live in the dungeon of ancient functional thought. And sadly, attitudes like yours ("why not just use C?") help promote this.

Actually, we have gotten out of the use of functional languages like LISP and replaced them with procedural languages like C. Which is good! That's what your computer does anyway. Though most functional languages do a very good job of implementing themselves in a procedural system... stacks are pretty simple things.

But I bet you're one of those OO people. You think that OO is the greatest thing and that if everyone used it to write their programs, the world would be a fantastic place.

There's a place for OO languages. They do some things well. Some things they do very badly. And in the end, OO languages are still only as good as the programmer. And they have enough problems and complexities that for things like flight control, they aren't always appropriate.

Let me tell you a little story. There was once a class that was trying to make a robot arm play ping-pong. There was a camera that could see the ball, and then the software computed where the paddle should be, then was supposed to move there so that the ball would return to the other side. The software was written in a "safe" language.

When they went to test the robot arm, the ball flew straight past it. The arm didn't budge. They looked at each other, wondering what the bug was, until a few seconds later the arm moved to where it should have gone.

The problem was the environment. After doing the complex computations, the garbage collector decided it needed to clean up all the memory used for the calculations. Once the garbage collector had finished, the arm was allowed to move, but by that time it was too late.

And to finish off, let me tell you the one thing that bugs me about most languages: THEY DON'T HAVE BUILTIN MACRO PROCESSORS. Macros in C are the most useful thing about the language, in my opinion. Not having them is a horrible travesty.

Re:Ada ?

[foobar104]

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!

Slight difference - These reboots are much faster

[deranged unix nut]

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

On Debian? Probably more like:

[Just Some Guy]

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.

Very good reason not to use Java:

[marhar]

From the Java License:

"Software is not designed or licensed for use in on-line control of aircraft, air traffic, aircraft navigation or aircraft communications; or in the design, construction, operation or maintenance of any nuclear facility. You warrant that you will not use Software for these purposes."

Why java cannot be used in a realtime environment

[rebelcool]

2 words: Garbage collector.

The garbage collector in java is an asynchronous type. This means while it is running its collection procedures (which can begin at any time, there is no way for the programmer to control this), processing of the program code halts.

I had a professor which demonstrated the problem of this in a simple example. Suppose you are designing a robot which can climb and descend stairs. It must monitor sensors and adjust angles of its joints appropriately to go down (quite difficult, really). Now suppose the GC runs halfway through the middle of a step. All processing stops, gravity takes over, robot falls down.

Same goes for avionics systems, if you're landing a plane, you don't want your HUD display to suddenly freeze as you're descending at several meters per second. You'll descend straight into the ground.

Hence the reason java puts a clause in its license about no use in safety-critical applications.

Re:Ada ?

[_xeno_]

It is possible to let an Exception cause a Java application to "crash", although it usually exits fairly cleanly, or, if the exception occured as the result of an event in a GUI, just continue on it's merry way, with the given function having been aborted.

The Java compiler forces people to catch any Throwable that does not extend either Error or RuntimeException - assuming that the given exception is noted in the throws clause of the method it's looking at. However, as far as the Java runtime is concerned, any exception can be ignored. (So if you managed to compile against classes that claimed not to throw a given exception and link at runtime against code that does, an uncaught exception can wind up "crashing" the program.) An ignored excpetion just propagates up the stack (well, the stack of called methods), until eventually it gets caught by the root exception handler in java.lang.Thread.run(), which simply dumps the stack trace and then destroys the current thread - in essence, causing the application to "crash", although it's really just an uncaught exception.

To prevent that, just

try {
// your code
} catch (Exception e) {
// Either fix it, or restart, or something
}

Generally speaking, Errors should not be caught because they're basically signs of the underlying system getting ready to go out the window. (Except for StackOverflowException which is usually a sign of unchecked recurrsion...)

Oh, and you should add something to your list of problems - the completely inconsistant and confusing versioning numbers that Sun uses.

Since as you do complain about the fact that Sun uses Java to mean both the language, virtual machine, and class library, the Java version number is just plain confusing since it applies to all three.

As an example, when Java went from version 1.0 to 1.1, there were several changes to the language (the addition of inner classes), several changes to the API (a new AWT event model), and changes to the JIT technology backing the virtual machine. This pales in comparison to the absolutely stunning Java 2 release.

See, when Java 1.2 was released, half the documentation called it "Java 2" - which is understandable, since there were many additions to the default class library (Graphics2D, Collections, Arrays (which adds the qsort that was missing, BTW - it's java.util.Arrays.sort(java.lang.Object[]) - oh, and because Object[] isn't the same as int[] etc, they have special copies of the method for byte[], char[], double[], float[], int[], long[], short[], and of course, Object[].)

Java 2 - or Java 1.2 - also saw the default JIT be changed to the HotSpot JIT. I think Java 1.3 changed the compiler, as well as adding new classes, and 1.4 changed the language to add an assert feature - involving another change to the compiler...

Anyway, I still do write Java as my day job, and it's nice to get that off my chest... ahhhhh...

Re:Why a reboot - because the creators are bozos

[TheStruuus]

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.

MS Pilotclip

[zCyl]

Hello! It appears you are trying to fire a missile, would you like my assistance?