Slashdot Mirror
F-22 Avionics Require Inflight Reboot
An anonymous reader writes "The Atlanta Journal & Constitution is fronting a lengthy piece on the USAF's new F-22 and its upcoming shootout with the existing fleet of F-15's & 16's. One line in the article really jumped out at me: 'When avionics problems crop up now, pilots must restart the entire system as if rebooting a personal computer.' I did some googling, and this is about as much as I could find: The hardware backbone for the system is the Hughes Common Integrated Processor, which, in turn, appears to be built around the Intel i960 CPU. I couldn't find a name for the operating system, but it appears to be written in about one and a half million lines of Ada code; more on the Ada hardware integration and Ada i960 compilers is here. Any Slashdotters working on this project? If so, why do you need the inflight reboot? PS: Gamers will be interested to learn that nVidia's Quadro2 Go GPU and Wind River's VxWorks Operating System are melded in the F-22's Multi-Function Display."
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.
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!
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.
Stop the brainwash
> Software functionality should not be fundamentally different from hardware functionality.
Am I to understand that you are saying that software, like hardware, should only fail when it fails?
Granted, we have a software reliability crisis on our hands. But hardware isn't generally fault-free either. I've had a lot more Zip drives die on me than I've had kernel panics. And arguably a kernel is much more complex than the design of a removable disk drive.
> An algorithmic system is temporally inconsistent and unstable by nature.
That's an absurd claim. It's possible to prove correct behavior for algorithmic systems. Time is explicitly accounted for in most such proofs.
The biggest engineering difference between software and hardware is that people find software errors acceptable, or even normal, whereas they have never reconciled themselves to, say, collapsing bridges or wings falling off of airplanes. When that attitude changes we'll start seeing software that rivals hardware in reliability, not before. Most of the engineering concepts required for producing good software have been around for quite a while.
Sheesh, evil *and* a jerk. -- Jade
[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
unfinished: (adj.)
I will certainly grant that Win2k is a significant improvement, and perhaps an order of magnitude more reliable than NT4. I don't generally count Win98 in these comparisons; even very few slashdot trolls will stand up and try to make a go of claiming Win9x/Me exhibits reliability of any kind.
However, to put it in perspective, doing normal development with Java, VBScript, IIS, MS SQL Server, MySQL, Flash (I am deliberately excluding crashes that occured while coding C/C++ and other "non-safe" systems), I observe Win2k either bluescreening, spontaneously rebooting, or getting to a state where it needs to be power-cycled approximately 2-4 times a month. This seems like heaven compared to NT4, which I I used to crash daily while doing Java development and writing ASP pages for IIS. Most NT4 production servers I am aware of are rebooted regularly, often nightly, to prevent them from falling apart altogether. My experience with NT4 has been unequivocal. Don't use it in production unless you want to suffer.
That's not counting Win2k's constant explorer crashes, which are generally not disruptive but still a bit unsettling. The majority of the problem appears to come from Microsoft being unable or unwiling to sanitize the GUI code and protect failures to handle the GUI layer correctly from killing the entire system. That, and I still see the standard device-related problems. Burning CDs and attaching new mice have both proved catastrophic for Win2k, in the latter case requiring a complete reinstall of the operating system. No, I didn't build the mouse myself; it was a Logitech mouse.
I also note that, as with all other versions of Windows, Win2k still has a tendency to "decay;" that is, to continually develop small but uncorrectable problems until reinstall is eventually required. However, the decay rate also seems to have been slowed.
Compare this to Linux, which I also give daily and roughly equivalent use, and which _never_ crashes. _Ever_. In fact AFAIR the last time I had to deal with unexpected shutdowns on Linux was due to a foolish attempt to build a complicated high-speed SCSI chain a year or two ago. I am not aware of any problems on Linux which cannot be corrected without a reinstall of the OS, but perhaps there are exceptions in the crowd who can share experiences.
So... Win2k. Finally usable. But still not competitive.
To all knee-jerk anti-MS-criticism-on-slashdot and pro-MS trolls... if you're just skimming, now is the part where you hit reply and do your thing.
We're on the road to Tycho.
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.
Anonymous Cowards suck.