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."
...Blue Skies of Death
That's what happens when you use ADA. If it was in Scheme we'd have no problem.
Openoffice 1.0.1 was released a few days ago and it didn't make the headlines. However, development releases of Linux do. Strange, eh?
Got friends?
My system (Windows ME) hangs every time I try to use Restart. I hope their avionics system is more stable, or those pilots are in trouble...
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).
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!!!
There comes a time in every man's life when he must say, "No mother! I do not want any more Jell-O!"
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.....
----- One piece short of Legoland
Boeing, responsible for integrating the F-22 Raptor's advanced avionics, has been testing software packages in both its avionics integration lab, or AIL, since 1998, and on its 757 Flying Test Bed, or FTB, since March 1999.
Both the AIL and FTB are helping reduce avionics risks and contain development costs by enabling extensive evaluation and troubleshooting before full avionics are ever installed on the F-22. Testing in the AIL and aboard the 757 FTB has allowed for early delivery of avionics Operational Flight Packages, or OFPs, to the F-22 test aircraft.
To date, Boeing has completed more than 21,000 hours of avionics testing in the AIL and 800 hours on the FTB.
Despite an accelerated delivery schedule for the year 2000 to support the Defense Acquisition Board, or DAB, requirements, the Boeing Avionics Integration team was able to integrate, test and deliver all Operational Flight Programs, or OFP's, ahead of plan. This included delivery of the Block 1.2 OFP on July 5, 2000, and Block 2/3S OFP on July 20, 2000. The AIL was also able to deliver the Block 3.0 OFP Engineering version to the Avionics Flying Test Bed aircraft a month ahead of schedule (Sept. 4, 2000) to allow for early testing and maturing of the OFP, which resulted in the first demonstration of multi-sensor fusion (Sept. 13, 2000).
The most significant accomplishment of the AIL for 2000 was the delivery of the Block 3.0 OFP, the first fully integrated avionics package, to F-22 aircraft 4005 on Nov. 21. This was a critical milestone since the Block 3.0 OFP was the first complete avionics software package to be flown on the F-22 aircraft, one of the most challenging DAB milestones accomplished to date.
The Boeing Avionics' Systems Engineering team's performance testing on the radar has resulted in all Test Performance Measurements, or TPMs, meeting or exceeding specification requirements. A significant milestone was reached on Nov. 15, 2000, when Raptor 4004 conducted its first flight, and targets were successfully detected and tracked in the air. Performance of the radar system was described as "eye-watering" by the pilot who flew the mission. A second major milestone occurred on Jan. 5, 2001, when Raptor 4005 flew for the first time utilizing Avionics Block 3.0 with the full complement of Radar Modes incorporated. Once again, targets were detected and tracked at long range, and the radar performance was outstanding.
Avionics Radar and Power Supplies Production activities continue to be a high priority. All shipments for PRTV I have been completed, PRTV II shipments are well under way, and hardware manufacturing for Lot 1 has begun. In the area of affordability, the implementation of Boeing-funded process improvements on several components of the radar/power supply systems, to include the T/R module and circulators, have been a tremendous success. The predicted cost savings have been substantiated in the first three production contracts and the targeted cost savings of $350 million dollars over the production life have been legitimized.
The next critical avionics milestone is delivery of Block 3.1 avionics. Block 3.1 will provide additional functionality to the F-22 Raptor and allow it to accomplish a significant amount of flight testing. Block 3.1 is scheduled to be delivered to Lockheed Martin this fall.
Overall, the F-22 avionics program is very much on target in the areas of performance, cost and schedule. The avionics packages have been performing exceptionally well, and all major milestones have been met on or ahead of schedule.
If voting were effective, it would be illegal by now.
Gives "Blue Screen of Death" a whole new meaning...
Apparently, the reboot is only necessary after discharging ammunition. The hardware configuration wizard will pop up and instruct the pilot to reboot the system in order to activate the changes.
"I have opinions of my own, strong opinions, but I don't always agree with them." -- George H. W. Bush
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!"
they sure wouldn't be able to say anything about it.
Yeah and all the flight sim pilots claim that getting shot down was due to lag induced by running an old set of Detonator drivers and not by getting sniped.
This guy does. This guy does!
But nope, can't find Win98 here. Sorry, maybe check those cash registers at target. I think maybe those bank signs that tell the temperature might run in Win95. You'll find something.
Please tell me you told her about Bresenham's integer circle drawing algorithmn...
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.
If voting were effective, it would be illegal by now.
Sorry, username/password incorrect, plase try again
*damn* what was that new password?
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!
Everyone knows that frequent reboots prevents crashes.
Sheesh, evil *and* a jerk. -- Jade
In 1997 the Mars Pathfinder probe had a problem with VxWorks and priority inversion. Perhaps the F22 is having something similar -- whenever you have a RTOS, the designer must try to anticipate when it's safe to block real time interrups and when it isn't. I don't know anything about the F22, but it's easy to imagine that it has hundreds of input sources with all sorts of latency requirements. AFAIK, it all comes down to some humans trying to balance these conflicting needs. Clearly they don't always get it right.
It's so todays pilots feel more at home with their fighter jets computer of course, having grown up with 90's software. You haven't seen the changes to communication protocal yet have you?
typical conversation between pilots
pilot1: u missed ur target fag u suck
pilot2: stfu idiot i'll kik ur ass
pilot1: lol ill show u how to shoot missles loser... im gonna get that camper anti-aircraft fag
pilot2: haha u missed 2... u couldnt even hit ur fat momma
and so forth....
This comment was generated by a Squadron of Ultra Ninjas
Maybe they should have gone with something more tried and true, like *nix, rather than writing their own custom code.
No offense, but... eat a dick.
*nix is not the solution to everything, no matter how much you may think this is the case.
Aw, fuck it. Let's go bowling. - The Big Lebowski
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"
If voting were effective, it would be illegal by now.
The idea of one of these with a broken reset button, adds a whole new meaning to the word 'crash'. In fact, it's more like 'crash and explode, charring everything within a 1000 foot radius'. Yay.
using namespace slashdot;
troll::post();
And just what we'll happen when you reboot in Midair? I guess you can't run any programs. When I get in to the Air Force, I'm bringin Linux and BSD with me!
We're Doomed
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!
Here, the planes are pushed beyond normal limits by test pilots who cartwheel them through the sky at high altitudes and race at supersonic speeds a few feet above the Pacific.
Man - that would make pod-racing looking like drag-racing snails... 750+mph just feet above the ocean?! Imagine the wake behind that beast.
Also, can anyone confirm if OSA is the name of the referenced ADA software project (1.7 million lines etc...)
Gmanske.
Ah, 3am then, but now I'm all done by midnight.
I needed four ints per tickmark then or most likely 180 ints all told. Of course you should be able to make these shorts as store not actual points, but vertical and horizontal offsets from the center of the rose.
Apparently one cannot even speculate about modern weaponry without falling victim to TMFA (Too Many Fucking Acronyms). I've often debated over who's TMFA was worse: Micro$oft or the guv'ment. Perdo here is really making a strong case for the latter.
I'd rather have a full bottle in front of me than a full frontal lobotomy.
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.
when the nato bombed serbia, sometimes they hit civilian houses because of such errors.
know what?
war sucks
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
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?
--
"we live in a post-ideological world..." - Billy Bragg.
Northrop Grumman's competitor was the YF23, which was rumoured to be superior in some areas to the YF22. I've been looking on Google for info and all I can find is nonsense about black projects and flying saucers. Does anyone have any links to real information?
Stick Men
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....
Gmanske.
They're having trouble recruiting new pilots today because they're sick of campers sitting there using their anti-aircraft guns.
That was funny. You roX0r.
As my father lik@(munch munch)...
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.
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?
Oh well old habits die hard I guess.
When these guys start to adapt the research from AI low level bug's etc instead of unfuzzy logic of the "Do this" and "crash", the concept of reboot or give up and start completly over can finaly be removed. Then self repair correcting for damge problems can finaly be added giving the pilot or who ever a better chance of surviving. Basicaly a way to heal itself so to speak.
If so, how will it be implemented, cos I reckon my PC could do a pretty accurate version...
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...
I'm trying to teach myself to set people on fire with my mind... Is it hot in here?
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).
My other first post is car post.
The part from globalsecurity.com (that one that says the system has about 1.7 millions lines of Ada code) says this:
Ninety percent of the software is written in Ada, the Department of Defense's common computer language. Exceptions to the Ada requirement are granted only for special processing or maintenance requirements.
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 ?
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.
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
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 :-)
My Aurora : http://www.youtube.com/watch?v=o91ZsGwJYyg
FB : https://www.facebook.com/TanveersPhotography
I first read the article title as "F-22 Avionics Require Inflight Robot"...at which point visions of R2 units on USAF craft started dancing in my head. I got 1/2-way through the article without seeing any mention of an astromech droid before I realized I read the title wrong...how disappointing
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 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.)
I doubt, therefore I may be.
Even though they get a lot of bad press, the only reason why the planes fly are Boeing and Airbus. If it were up to pilots the planes would crash more often that Windows 95 boxes.
I remember sitting inside a Lufthansa plane on the Munich airport waiting for the plane to taxi. Sudenly we hear this very loud noise from somewhere below. The plane doesn't move and the noise goes on for 10 minutes or so. Then it suddenly stops and after a short pause the pilot gets on the intercom:
(Strong German accent:) "Ladies and Gentlemen: We had zi small problem witz one of our computerz. But now we've rezetet it and everything seemz to be OK."
After a short pause he adds:
"It waz very cold tonight here on zi ground, zat must have cauzed it."
Oh shit.
have a look at this. i'm not saying the f22 does this, but the concept is not ridiculous!
Acts@core.mailboks.com Acrux@core.mailboks.com Adam@core.mailboks.com Adar@core.mailboks.com Ada@core.mailboks.com
> 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
I was just installing various things to my win2k box and it still wants rebooting when:
Nero was installed,
when VIA 4in1 was installed,
when ATI catalyst display drivers were installed,
when I changed pagefile's size,
when I changed access mode for IDE device from PIO to UDMA...
Preserve old classics: copy your collection onto all hard drives.
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. The fourth and fifth rows from the botttom of the page have photos of the F-22. The best one is here.
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 working on stuff that at some point would *require* an implicit reboot of the system any time hardware or software failed, or perhaps even a new mode was selected.
This sounds worrying until you realise that the requirement for a "reconfiguration" is such that it can be performed in-flight.
Perhaps the Wintel crew need to look at making their reboots non-intrusive!!
Whatever.. isn't this COSA thing just Occam? It's not like there's a Transputer on every desk.
Why do you say C? Is it just because "everyone uses it"?
C is a horrible choice for oh, I don't know, just about EVERYTHING.
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. We STILL live in the dungeon of ancient functional thought. And sadly, attitudes like yours ("why not just use C?") help promote this.
With the ascendence of C, all "other" language design has almost completely stopped, and that's just pathetic.
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?
Hope your principal wasn't as excessively sensitive as your teacher.
Note to M1-ers: a curt but otherwise insightful message is not "Flamebait" or "Troll".
Just as a note to chrisd, any Slashdot reader who is also working on the F22 avionics would be working in a TOP SECRET environment. Which loosely translates to a) they couldn't tell you they even working on it b) couldn't even read Slashdot while at work because TS environments are not allowed access to the Internet.
Just as an FYI, but then, who wouldn't expect Slashdot editors to say something stupid?
Hmmm...
neural networks, cellular automata and the like...
Don't see how we gain any provability by a simple reformulation like this - and for sufficiently complex stuff, algorithms are easier to understand and more easily predictable than a (possibly self-modifying) neural net.
Someone pass the Wolframite, please
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.
"I have never let my schooling interfere with my education." - Mark Twain
My keyboard function keys only go up to F15 !!!
"You have liberated me from thought."
They were the first ones with ?th generation jet fighters. I wonder if the Swedes have same kind of problems. It is more advanced in the avionics. No I am not Swedish. I hate them.
Yes, you do have to reboot the computer if one of them fails. However, the F-22 has 3 redundant computer systems, so that if one or two go down the remaining one(s) take over while the bad one is rebooted. If its a more permanent problem, say the computer is shot, well then you cant really reboot that. And if all of your computers go down? Reach between your legs and pull the ejection lever, because the plane is not only unflyable without computers, it wont even glide without a computer.
[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.)
Years ago, a friend of mine had recounted a tale of an Airbus rebooting on the tarmac for reasons the pilots described as the "big red light" being on. Guess it's not just the sexy aircraft that needs to shake its rebootie from time to time.
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.
I don't know about everywhere, but the college I attend has the computer science program as part of the engineering college. We both get Bachelors of Science as well.
So, how is being a "real engineer" different from a "science person"?
Last time I checked, the only difference between computer science and computer engineering was that the engineers are more geared towards building processors and integrated circuits whereas scientists are preped for software design.
And BTW, software DESIGN is taught in college as part of the CS program. The idea that most programs are simply written by a single programmer who sits down and start spewing out code has been wrong for many years. But even the best designs still have flaws.
kc8apf
I can't believe what I just saw. Two people having an honest and decent conversation on Slashdot. Heck, why rip Slashdot in particular? Seeing that kind of thing on a web site at all is refreshing.
Move along. Nothing to see here.
the fly by wire system in these planes was developed at Texas Instruments;in the late 80"s; the unit consists of a variety of single daughter board computers integrated into a larger motherboard. Interesting names; like the vector arithmatic logic unit (VALU),as I recall, there was the VAGU,and 4 other boards.I don't remember all the board names. They were developed under DARPA's Very High Speed Integrated Circuit (VHSIC)program, in which I worked.
shit, they BETTER ERROR TEST IT BEFORE THEY FLY IT. Its ok if your pc crashes every once in a while. Its not ok if your fighter crashes EVER
... appears to be built around the Intel i960 CPU
Cool! My old HP XTerminal has the same...
And it only reboots about once a year when I turn it off myself.
As a former F-106, -4, -15 and -16 ground crew (Weapons) person, I can say this is not an unusual occurance. The F-16, for example, occasionally requires a reboot to some of the ancillary systems inflight. The SMS (Stores Management System) being probably the most needed.
Jet fighters operate in an unbelievably harsh environment. High and low temps, high G forces, vibration, etc, etc. It's a wonder they get it to work at all.
Slashdot fodder:
For maintenance, diagnostics, and troubleshooting, the groundcrew uses laptops. Armored, waterproof, etc. Plug it in, and the jet tells you more or less what is wrong. The maintenance manuals are all on CD. These laptops are running on...wait for it....NT.
Why not Linux? Because even if it is demonstrably more stable, the specs for the F-22 were laid down several years ago, when Linux was but a wet dream. Too late to change now.
Do you think they'll be playing Solitaire on their HUD on the way to a sortie?
You know, this is something that I'd rather not know about, because if I can find all this information about our most advanced tactical fighter, then some "less desireables" can find the info too. Somethings are just better left alone.
Whatever man, I spelled it write!
My first job out of college was working on F-16 avionics during the 1980's. I was surprised to find out that F-16 pilots often power-cycled the Fire Control or Stores Management computers when glitches occured. I don't know if the latest F-16 software and hardware requires such measures but they were not uncommon back then.
As an aside, early F-16 A/B aircraft used magnetic core memories, which are non-volatile. The computer could be power-cycled without losing data. And in the case of an aircraft crashing, analysts could recover the magnetic core to help in post crash diagnosis.
...get it to run on a cash register or something.
Mebbe I can then get it to fly and fire sparrows at other unidentified flying things...
~!nrk
.sig(Anarchy Rules)
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).
Any Slashdotters working on this project? If so, why do you need the inflight reboot?
Yes I have entensive knowledge of the internals. I can say that#stat.372//Carnivore active#
I haven't worked on the F-22, but I coded the Korean T50's OS and a new Navy IRaD FADEC.
At anyrate, the OS's aren't OTS, but designed and coded for each plane (Ada for all the military boxes). As for reboot, if the system becomes hosed, for any number of reasons, the Avionics will reboot. This is true in all aircraft, even your passenger planes.
They key thing to remember is that all of these systems are atleast dual redundant, meaning that the entire system doesn't reboot, just one channel. When that channel does reboot, the reboot is done in less than 200ms. (Usually faster).
This isn't like Windows where a reboot can take minutes, and you'll blue screen when it's finally running anyway. These are unique, tried and tested OS's, which operates with a Probability of Loss of Control around 0.3%
== Eagles may soar, but weasels don't get sucked into jet engines.
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.
on.
Embedded systems (70s) used to be a big loop with a goto at the end. A couple of libraries provided hardware interface. I've worked on projects (still flying) where the processor, instruction set, assembler, compiler, linker were an in-house design, so every detail was well understood.
Now we start with an OS that's many times larger & more complex than the entire application used to be. Often it's a proprietary OS that is executable only, but even if you get the source nobody has time to really develop an understanding.
Is this additional complexity making it easier to field an application but at the cost of reliability & usability? Have we gone too far?
BTW: I'm no longer in Aerospace, but still working on high availability embedded systems.
"Glory is fleeting, but obscurity is forever." --Napoleon Bonaparte
MS Support: Thank you for calling Microsoft. Your call is very important to us. Your call will be answered in the order it was recieved.
F-22 Pilot: #$@@#%%(@!!
MS Support: o/~ The girl from iponimia dah dum dee dee. Duh dum dum dum da dee dee dee dee... o/~
BOOM
If it was Linux, it wouldn't crash but the pilots would constantly complain about how ugly the fonts were on the display.
This sig has been temporarily disconnected or is no longer in service
Right before Luke blows up the Death Star.
"Luke, you've turned off your targeting computer. What's wrong?"
"Fucking Windows, that's what's wrong! Now I gotta use the force!"
>
9/11 NEVER FORGET!! The terrorists are everywhere! You're a terrorist! We're all going to die because the machines rule the world!!! There's no backup!!! THERE'S NO BACKUP!!!
I was an intern a few years back at a company that did the flight management computer for a different commercial and military planes. All I did as an intern was take the binary logs returned from one of the commercial series planes and run them through a decompression utility that spit out plane text. Then pull out the messages from errors that had been fixed in newer versions. Then I passed the info on to the engineers who fixed the problems. It was amazing how often the FMC would reboot on an uncaught exception.
It never seemed to cause that big of problems (not that I ever heard what the pilots were saying when their screen went down,) but then this was a plane that still had all the analog readouts and everything. I would hate to think of something like that on a plane that's fly by wire.
Wow. You used they're, their, and there correctly in a single sentence. You must be new here.
Sitting on the tarmac waiting to push out from the gate. Lots of time passes. The captain comes on the horn to say that they were taking some manual fuel measurements to cross-reference with a questionable cockpit gauge. Eventually, they shut down the whole plane, one system at a time, until it was completely dark and still. Then, they started "booting" it back up, one system at a time. Eventually, the captain came back on to announce that everything's ok. There is something vaguely troubling about sitting through a Boeing reboot...
____DevManager_____
One of the complaints often heard from fighter pilots is that their computers or screens crash. They have to reboot them all the time. I have heard of pilots quip about rebooting a dozen times on a mission.
//TODO: Think of witty sig statement
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.
I was just installing various things to my win2k box and it still wants rebooting when: ...
Generally software installs ask for reboots because the software author didn't feel like actually determining if a reboot was necessary. They just prompt for a reboot to be safe. 9 times out of 10 it isn't necessary in Win2k - just click 'No' and try.
I know this works for Nero. I don't think the ATI Catalyst drivers actually needed a reboot either for me.
I don't recall having to reboot when changing the pagefile size (or even being prompted)... in fact, Win2k often resizes it on-the-fly.
Even changing the machine's IP from static to dynamic doesn't require a reboot if you go (re)start the DHCP client service.
MS just feels safer asking you to reboot, because you might have ignorant software running that isn't aware of the changes. A reboot ensures that such software comes up in a known environment. Most programmers who write Windoze software are too lazy to detect certain changes at runtime.
NGWave - Fast Sound Editor for Windows
The problem with the moderation scheme is that a known troll like this guy constantly gets moderated up by someone who isn't aware of his "quirks." What this guy is presenting is unproven and not peer reviewed. His ideas run counter to common practice in software engineering.
One of the key design aspects of this aircraft is the nature of it's redundency. The aircraft is a dual processor system giving each system at least dual redundency.
The way the government goes about creating this dual system is pretty interesting. Two seperate companies are contracted to design two different systems running on different processors to accomplish the same task. These companies are in different cities and have no contact with each other in order to make the two designs as different as possible.
A flaw in one processor will not be found in the other and a flaw in one system design will not be found in the other. This reduces the odds that a pilot and a $22,000,000 aircraft will fall to the ground.
Welcome to the land of the free...pay toll ahead...no photography...please open your bag...
Actually, this feature was added when the pilots complained that all of the fly-by-wire crap, and other workload reducing measures, left the pilot with nothing to do but sleep and shoot.
;-)
Nothing better to keep a body alert than the dark cloud of a fiery death
Eve Fairbanks says I drive a hybrid!LOL
True story.
A300's still run a version of the 8086. In the early days there were problems getting the planes to land. The pilots would line up the runways, start a descent, then the plane would override the landing and take off on its own. From the cockpit the pilots called tech support in Paris who finally suggested rebooting the flight systems.
good job for pointing out that there really IS a diff between computer science and engineering. its a whole different mentality for one...however, the whole "design 50 times over before u write" is a bit excessive. u start with an idea and good system structure. it should be more like: design, write, design, write, test, design, write...ad infinitum. it is nice to do design and discussion, but there are FAR too many problems that are evident only once u start actually writing the software. if the writing of the actualy software is so inflexible that there is no room for redesign, you will end up with some pretty bad software. personally, i think the KEY thing to any good software is:
only one person should be writing it.
each additional person you add to the project does not yield another person in terms of work. maybe 0.6 of a person, if communication is ideal and he is a good programmer. otherwise, it is much less. if one person writes it, there are no inconsistensies that can ruin projects, simply because the 2 (or more) ppl didnt talk amongst each other enough.
QED
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
I hope they're using something a little more stable than hard disks...taking off, landing, and other high-G maneuvering would wreak havoc on a hard disk. Not to mention jostling if hit by flying debris or enemy bullets...
In SOVIET RUSSIA... erm...NSA AMERICA, the Internet logs onto YOU!
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.)
It looks like you're trying to eject. Would you like me to
1. Open the canopy
2. Make a few impressive loops while you hover towards the ground
3. Never mind
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
Dewey, what part of this looks like authorities should be involved?
Engineers build real systems, and as such have to deal with all sort of outside constraints which are usually not considered in pure computer science curricula: the compromises introduced by tight schedules and limited budgets, unreasonable feature requests from marketing departments, etc. In general, having dealt with both camps, I've found that the "scientists" often dismiss real-world concerns on one of two grounds: either they're not theoretically interesting, or they're too theoretically complex to be realistically addressable. Engineers, OTOH, don't usually have the luxury of picking and choosing their battles like this. Engineers often dismiss pure theory on the grounds that it is insufficiently applicable. I have seen a number of cases where I don't think they were correct.
Last time I checked, the only difference between computer science and computer engineering was that the engineers are more geared towards building processors and integrated circuits whereas scientists are preped for software design.
"Engineers geared towards building processors and [ICs]" are hardware engineers. People "preped for software design" could be either software engineers or computer scientists. In fact, software design at the level of UML diagrams and the like is more likely to be covered in a software engineering-oriented course than in a pure computer science course - since it's not really a topic of interest in the pure computer sciences, having more to do with human factors and communication than what is mathematically provable or computable.
Of course, many curricula involve some (not always rational) mixture of both science and engineering, which in part reflects how new the entire discipline is - it will probably stratify even further in future.
Sorry but any data about the on-board avionics and its software can't be shared by those working on it.
If it were a Bachelor of Cheese degree handed out by the same institution would it make a difference?
Labeling it as "science" does not change the culture it exists in, or the expectations software projects exist under.
These are the things that make software less reliable, and software engineers, less like "real" engineers.
Software projects tend to exist under time, and budget constraints that a hardware project manager would laugh at.
As has been noted earlier, until the expectations of software are raised in general, the performance of software, in general, will barely meet them or fall just short. And the community that develops it will mirror that.
Old truckers never die, they just get a new peterbilt
I do work on parts of the F22 project and I haven't heard any of this here. This aircraft will be one of this nations best when it is put into production. I really wish I could say more, but pretty everything I don't work on is classified, and everything I do work on is property of the government/company I work for.
If they use VxWorks in one part of the avionics then I would imagine they are using the same OS for all systems. AFAIK VxWorks is a realtime OS.
only one person should be writing it
Which works well, unless you subscribe to the extreme programming paradigm. In that case, you're never supposed to have a single programmer working on the code - always two there are...
"I have never let my schooling interfere with my education." - Mark Twain
The CIP does not use the simple "printer controller" version of the i960 but the i960MX variant. The idea was to have a fault-tolerant system with hardware enforced capability-based security. The desire for fault tolerance is obvious but why would you want fine-grained security enforcement on an airplane? The concept was that you could have a tech with just a low-level clearance able to perform maintainance on a system that might contain more sensitive data.
Another reason for the i960 is that it supported some of Ada's features very well. For this type of system, you need both good speed and high code density. There is not a lot of memory on these systems as both board real estate and cooling are significant issues. You also want fast interrupt handling and timing predictability and the i960 was better at this than the "competition" of the time (e.g. R3000).
The CIP used many of the same ideas as the BiiN system (which also used the i960MX and an Ada OS.) Also note that the CIP is a backplane design: there are other processors in the mix including dedicated signal processors.
And they should respond to you and 10 minutes later be carted away from their office in handcuffs for violating all sorts of laws and agreements?! Work on this type of military hardware is absolutely classified which means you Joe Slashdot have no business knowing it.
Stupid me, I read in flight *ROBOT* and I was wondering when the AF was going to start producing R2 units...
i obviously need more sleep.
all vital technical system are duplicated onboard. They are duplicated in a very odd way in that they have the same spec of processors, and electronics and wiring components from two sources. Not just buy two from the same manufacturer and rid them together. No they buy two from different manufacturers (that have proven they have no upstream shared source) and they rig them together.
This is supposed to make the likelyhood of a phantom flaw unlikely to bring down the plane.
members are seeing something, your seeing an ad
When you are prompted to reboot while using a third party installer, you might want to blame the company that created the application you are installing. It is rarely *really* neccesary to reboot after installing new drivers or applications. I seem to recall loading up drivers for my sound and video cards back on WIN2k with no reboot at all...just instant functionality.
Two packages, Ada.Strings.Bounded and Ada.Strings.Unbounded, were added to Ada in the Ada 95 standard. I think that Ada's string handling facilities are pretty complete. The GNAT compiler also includes regular expression packages. See http://www.adaic.org/standards/95lrm/html/RM-A-4-5 .html
Why the hell would they be using ADA? I know the Defense Dep. has a thing for this most painful of languages, but you have to admit using C, with its huge set of libraries and well tested debuggers and compilers would have been more efficient and cost effective. I tried learning ADA back in College and I stop because I saw no practical value in continueing to learn it. Yet I love Lisp so go figure? Anyway, the Russians are designing a new fighter as well. Any specs available? Or are they still to paranoid to share?
You wish.
Consider the USS Yorktown. I doubt the turbines were supposed to be running at jet speeds (frankly, the tip velocity of a ship-sized turbine cranking to those RPM is a frightening concept) but since the boat was sail-by-wire, when the Windows supervisory machines (and maybe `embedded' systems, we've all seen WinModems, we've all heard MS touting XP as embeddable, sorta) went down, it really didn't make any difference how close to the metal the failure was, that baby was a sitting duck for hours.
Now, if my F-22's display and controls go dead because of a display manager failure, am I any happier than if they go dead because of an engine failure or system-wide failure?
I guess I'm marginally happier than if the wings had simply fallen off, but only for a few more seconds. High in a clear sky, probably not a life-threatening issue provided that reboot is fast.
In combat, takeoff or hedge-hopping situations, not so good.
Got time? Spend some of it coding or testing
Given the fact that we are at WAR, is
it appropriate for you people to be
discussing F16 architectures?
You don't know anything really, do you, about
it?
It amazes me how people discuss things that
they know nothing about.
How much of this stuff is Classified?
Do you realize that your loose lipped
ego-based panderings-on here
could cause good people to be in much
more danger?
Well, no. A stall occurs when the wing exceeds the critical angle of attack. It can occur in any configuration (nose up, nose down, etc.) and at any speed. The problem is not lack of speed, it's the fact that the excessive angle of attack causes airflow separation across the top of the wing, which results in loss of lift.
As for the thing basically just dropping out of the sky: Also incorrect. In most planes recovering from a stall is a straightforward maneuver, and stall execution and recovery is part of basic flight training. Of course, if you're only a couple of hundred feet above the ground when you stall, you might not have time to recover. The other potential danger with a stall is that if you're flying uncoordinated at the time, you can get into a spin, though in most aircraft spins are also recoverable given sufficient altitude. Flat spins, such as the one depicted in "Top Gun", can indeed be a problem because the aircract lacks rudder authority in that situation, and rudder is important to stall recovery.
"Biped! Good cranial development. Evidently considerable human ancestry."
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.
-
If you let the SR-71's engines get wildly out of sync (say, pop a nose cone) the time from hale and hearty airframe to very expensive and very small confetti is about twenty milliseconds.
It wouldn't surprise me to discover that the F22's case was similar, ie, control system death becomes unrecoverable situation or structural damage in tens of milliseconds. The thing basically looks like a large set of anti-turbulence vanes with a fuselage holding them together, and probably wouldn't take kindly to an actual stall.
Got time? Spend some of it coding or testing
What if that app you're running is ISS? Or SQL Server? Or Exchange? Or another of the other Microsoft solutions, system services, patches, service packs, or other miscellany? But I suppose that's the "relying on coders who are [pretty much incompetent]" part you mentioned.
I'm very familiar with both sides. If you're open-minded enough to try, when you finish learning how to administer Linux, you will find it far more stable and maintainable, and the set of tools you'll use on it an order of magnitude more secure and reliable, than Win2k. _Let alone NT4._
I'm convinced the people who still run around touting NT4's reliability are either incompetent or not tasked with any particularly complex applications involving microsoft tools or both, not to mention not reading the news... Remember the hotmail disaster? And that was Microsoft's own team.
We're on the road to Tycho.
I used to do i960 support for Intel and heard an interesting rumor while I worked there.
Apparently, the i960Cx processors were released around the same time as the 386 and one of the engineers there had access to the Windows source code. He ported Windows to the i960 and showed performance 2x-4x that of the 386.
Management got word of this and quickly ordered the project canceled and all source code deleted. Intel was in the business of selling x86 processors to consumers. i960 was to be embedded-only.
Ah, so if I want my program to recover from a `kill -KILL' I need to write it in Ada? (-:
Got time? Spend some of it coding or testing
Jeez. That page says that Packages "was not a feature of Pascal". OK, first of all, Pascal is not a past-tense language. It's alive and well. Second of all, every Pascal implementation I know about supports Packages.
rat-ta-ta-ta... click
(Uh-oh!)
*reboot*
(Hurry up! Hurry up! Finally!)
rat-ta-ta-ta-ta
...an old joke. I once knew a guy who worked at Ford Aerospace. This was back when anti-lock brakes were still in their research phase. I asked him when they might go on the market. His response was that he had too little faith in software to rely on it to stop his car. His exact words: "It brings a whole new meaning to the halting problem!"
No, that just means your garbage collector needs to be a hard realtime implementation. If you can guarantee the collection will stop before the next critical time point, there's no problem.
And you meant to say the garbage collector is synchronous (blocking) as opposed to asynchronous (non-blocking). Although now there are garbage collectors of both types.
What are you talking about? Algorithmic systems are by nature consistent and stable. Inconsistancy and instablity are not caused by the algorhithms, but rather by
- the fact that we have largely moved away from an algorithmic model to an event-driven one, which is inconsistant and unstable by nature.
- Program states used to be simplified representations modelling reality (or fantasy). They increasingly base their state on raw reality. It doesn't matter how predictable an algorhithm is if you can't predict the state getting fed to it.
- Due to a combination of both laziness and overwork, as well as a preponderance of reinventing the wheel, most algorhithmic software-based systems use too much code that's too poorly tested to even dream of reliability.
Using the algorithm as the basis of software construction is an ancient practice pioneered by Lady Ada Lovelace and Charles Babbage.Jaquard also used algorhitms for his software construction, before Lovelace and Babbage.
Just because something is old doesn't make it bad, using the wheel as the basis of long distance land transportation is an ancient practice pioneered by someone who lived so long ago she isn't even recorded in the history books, that doesn't make wheels obsolete.
It is the fundamental reason why dependable software systems are so hard to produce.
The problems in producing dependable software are far far more complex than "we still use algorhithms", although clearly one of the problems is "we use algorithms where they are inappropriate". Algorithms work best where the computer is interfacing with mathematics and other abstract concepts, they work worst where the computer interfaces with the real world.
There is something rotten at the core of software engineering.
How can something that barely exists be rotten already? Software engineering has reached the terrible two's, it can (usually) feed itself, but it still runs around knocking over lamps.
Software functionality should not be fundamentally different from hardware functionality.
Huh? Most software has just the most cursory relation to hardware, it makes no sense to model such software after hardware. What would the hardware model be for a hypertext browser, for example?
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.
This statement only makes sense if you define "flexibility" far beyond its typical semantic meaning, as in "we don't have hardware that's flexible enough to draw an arbitrary projection of an arbitrary eight-dimensional surface" or "we don't have hardware flexible enough to perform statistics on multimillion element databases".
Even stretching the statement to make some sense, it's still false, since it ignores many things that software has that hardware lacks: zero capital cost, ease of replication, ability to ignore or rewrite natural laws. Tell the people writing software for ASCI White that their work should be an extension of hardware and they'll look at you as if you've got pink elephants on your head, the whole point of that computer is to avoid using the real hardware.
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.
I dare you to write a GAAP-compliant accounts payable system for a typical mid-sized corporation using a pure signal-based paradigm. I'm not saying it can't be done, but you will quickly see the advantages in software reliabilty and development productivity in using an algorithmic model over a signal based model when the purpose of the program is to follow a set of number crunching algorhithms.
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.
Abandoning algorithms won't "solve the reliability crisis". One important step towards improving reliaibility is making sure to use the right tools for the job. If you are writing a program to crunch numbers, algorithms are the best tool that I know about. If you are writing a program to control hardware, signal-response systems often make much more sense.
Even using these two paradigms you won't always be using the best tool for the job. Another potent tool is one of Mother Nature's favorites, the paired analog response system, where you have two (or more) complimentary analog systems (for example: the insulin/glucagon system to control blood sugar levels, the force/friction system to control accelleration). Signal-based systems can simulate this, but it can't match the precision of the truly analog processes.
More details can be found at the links below: Project COSA
Very very interesting work, I just see it more as complementing algorhithmic systems rather than replacing them. I see your work as particularly relevant for embedded systems (eg avionics systems like the story is talking about).
Note that, while your COSA system does handle events (signals) more predictably than most other programming paradigms, and it encourages more relaible code in response to the signal, it does not completly eliminate the two reliabliltiy problems I listed at the top.
To use your terms:
- You can't predict in what order sensors will trigger, making it possible to have unexpected effects when sensors trigger in an unexpected fashion
- Digital data and comparison sensors will never allow for a perfect decision to be made regarding analog reality.
I can't see a digital signal-based system getting away from these fundamental problems, the best you can do is come up with tools and methods that minimizes their effect.One other thing: You haven't gotten away from algorhithmic computing. I assume the algorithmic kernel is just expediency, it's cheaper to model COSA on an algorithmic computer than to custom design the right hardware. However, your descriptions of the operation of cells are all algorithmic, so the fundemental unit of your system is a handful of algorithms (granted, they're small reliabile-looking ones, but they're still algorithms).
----
Open mind, insert foot.
I've never really understood the sentiment of RTFM. I mean "Read The Fucking Manual"? I have read the Kama Sutra, and I fail to see its relevance in computing.
We do not live in the 21st century. We live in the 20 second century.
I thought it had been phased out, even in the military. Is there really any advantage to it, compared with C++?
I'm the stranger...posting to
The Swiss (whose military expenditure per capita match the US) have a saying:
Every country has an army in it. We just figure it might as well be ours here.
"Prepare for the worst - hope for the best."
I was a computer programmer(3C0X2) for the AF. Almost all my training was done using ada. In practice if the system was going into a plane it was done in ada; otherwise, we did it in C. We had to get waivers(pain) just to use C, but that is what we thought of ada. It's true ada helps elimate bugs by being a strict type cast lang. If I had to risk my life to a program, it would be written in ada. Most avionics use multiable systems which vote, so if you lose one system your still fine. 1.5 million lines, I bet that thing takes a week to compile it all.
The problem is that you read the moderation system the wrong way. Think of a high score not as "this is something that is true" but "this is something worth discussing, if for no other reason than to refute it".
Of course, naming the moderation as "insightful", "interesting", etc. doesn't help things.
I am not trying to dispute that Ada is a good language for critical safety related software... but it is only as good as the people and methodology/process being employed.
Consider the fact that the code for the Ariane 5 rocket which crashed because of a software problem, was written in Ada.
If I remember correctly, one of the last Osprey's to go down and kill a number of marines was due to an inflight reboot. IIRC, the pilot had a system error and rebooted but the system startup defaults were not designed to maintain flight. The in-flight reboot either was not designed for being in-flight or there was a serious hole in their QC process.
Either way, $billion flying machines which rely on so much software to fly, should have some low-level boot-kernel-like software to keep the bird flying when bad things happen. Or birds failing from the sky due to BSOD could get soo common they'll have a TV show about it...."When Bytes Attack"
Remember, a redundant system isn't much good if it too has the same software failure.
LoB
"Anyone who stands out in the middle of a road looks like roadkill to me." --Linus
The difference is simple--
"real engineers" are oriented towards problem solving, and making something that WORKS
"science person"s are concerned with discovery of novel phenomenna
In short--engineering is about getting the details right; science is about discovering what is possible. The problem with software engineering is that it is in general not disciplined enough to qualify as engineering.
I'm one of the few software engineers to have flown in an aircraft that was using his/her own code in the flight control systems. The Shuttle Training Aircraft flight software was written in Ada (83). I had the pleasure of flying on the STA during a training flight.
Ada95 (it's not ADA, it's a name not an acronym) is a language that will never become popular to the average programmer because the compiler won't let them do a lot of the very (unsafe) things that they rely on in other languages. This is the stuff you always read about...
The tools that an Engineer use are very important! You could build the F22 using only slide rules but I wouldn't fly it! You could even write the flight control system in C but by the time the process made it as safe as the Ada program. it would be out of date. Good engineering can happen in any language, Ada helps the process, C,C++ hinder the process)
Writing the flight control software in a language (tool) like Ada makes the end product more reliable and predictable because of both the compile time and run-time checks. I can make just about any Ada code execute as fast as C if I get rid of the run-time checks. Even then Ada is much better then C/C++ because of the compile time checks that C/C++ lack.
Writing software is an art and a discipline. most programmers forget the discipline part.
You'd be suprised at how often this is a required for nearly every fighter/bomber/strike aircraft.
In addition, even manual avionics suites need to be recaged (ie. rebooted).
yeah, right. you want somebody that worked on
this mess to come out and say "oh yeah, we knew
all abut this, but this level 3 manager down at
Alpharetta wanted to get his raise so we shipped
the usual stinking, steaming pile".
these guys make weapons for a living, remember?
Or more to the point, building bridges is hardly ever self-though as a hobby. In comparison, software engineering is possibly doomed at forever rewriting ideas which are short, simple and wrong.
Also, since most software cannot be returned for refund, even if ridiculously defective, hardware shops have that extra highly non-trivial financial motivation for double checking their work before pushing it out.
There is also a marketing problem.
It's all detailed in my report
This post was compiled with `% gec -O`. email me if you need the sources
When I first saw this headline I thought it said 'F-22 Avionics Require Inflight Robot'. I thought, "Cool! R2-D2!" Reading the article after that was a bit of a letdown.
I live ze unknown. I love ze unknown. I am ze unknown.
RTEMS is open-source, but it seems to have outgrown its Ada ancestry.
Aircraft control code is written in Ada because Ada was designed for real-time embedded applications such as these.
Of course, the operating system in both products above is a very minimalistic one indeed, and things like memory allocation and device management are neither abstracted away nor handled for you. This means that the work of writing a reliable device driver and making certain to deallocate memory after it has been used is left to the programmer to do. And many programmers tend to commonly make mistakes in these areas, causing many problems.
There's a company called Rockwell-Collins out in Iowa that builds and programs aircraft. I can't speak much more than these for specifics (I didn't work there, and NDAs prevent acquaintances from cluing me in) but I know that there is a great deal of testing before certification of the software for use by the FAA, and so hopefully enough bugs would be found and squashed by then that rebooting the in-flight computer should certainly not be a common thing.
Disclaimer: I am not an employee for RCI, nor have I ever been.
only one person should be writing it.
Which is fine, if all you want to do is write until you die. If, however, you actually want a product in a reasonable time frame, you must use >1 coder.
How long would it take you to design, code, test 1.5 million lines of code?
It depends.
The rules have changed with the arrival of insanely fast processor speeds. The CPU is so much faster than the memory bus that, on some architectures, it's MUCH faster to compute a sin/cos than it is to fetch the precomputed answer from memory, ESPECIALLY if you break the onchip cache and have to reach into main memory. Even worse, the lookup causes the processor to stall while waiting for the results of the lookup. Result? You've just screwed up the entire superscalar pipeline, flushed the cache, and stalled the hell out of everything because you tried to save a half-dozen cycles.
You never know until you test.
--
JonTurner
"We won't just shoot the bastards, but rip out their living guts and use them to grease the treads of our tanks."
-- General George S. Patton
Flat spins, such as the one depicted in "Top Gun", can indeed be a problem because the aircract lacks rudder authority in that situation, and rudder is important to stall recovery.
;-) )
Er perhaps you mean spin, or incipient spin.
In an aeroplane where the thrust component is inline with the CG and the aerodynamic centre of pressure, such that there is no rotational (yaw) moment generated by the powerplant, there would be no need for rudder when recovering from a co-ordinated stall.
A spin however, where you are wishing to neutralise the rotational component before recovering the stall, you'd need rudder authority. ( A spin is an asymetric stall where one wing is generating more lift than the other, causing a rotational moment about the yaw axis. -- not entirely correct, but more correct than not.
Blue screens in the morning,
Ground crews take warning.
Blue screen by day,
Stay outta the way.
Blue screens at night.
Reboot, and take flight.
How many karma points would that cost?
i have seen plenty of full blown wonderful projects written by one person. i am also talking about initial development, not supplemental additions.
QED
BSD is for people who love UNIX. Linux is for those who hate Microsoft.
All this hoohaw about the OS is fine and well, and the stealth characteristics of the F-22 are nice (although likely to be countered sometime before the end of program life by LIDAR, passive EMF bounce, UWB radar or some other technology), but the really big billy bad boy aspect of this plane is the supercruise (otherwise known as flying at cruise power at over Mach 1).
Supercruise gives this plane the ability to cover far greater distances in less time, with less refueling then would be required by F-15s running the same circuit at the same speeds. That translates to a far greater amount of territorial coverage for defense per plane, a terrifing capacity for a dash attack and an ability to have a lethal number of F-22s converge on a crucial position.
Simply put, fewer F-22s will be able to defend more space, threaten attacks to keep an opponent on the defensive across more territory, and concentrate for overwhelming superiority.
The F-22s' greatest capability is this operational superiority. Air forces across the world are trembling at the prospect of facing this beast.
________________________________________ History Must Not Fall Into The Wrong Hands ___________________________________
Moderation Totals: Flamebait=1, Troll=1, Insightful=1, Interesting=4, Funny=1, Overrated=3, Total=11.
Interesting moderation totals. I must have struck a sensitive nerve. For the record, my site received over a twelve hundred hits in less than 12 hours after I posted my message on Slashdot. I thank the few enlightened souls who were kind enough to email me their words of encouragement. Stay tuned. There is much more to come.
Project COSA
hah someone mod this up!
Outdoor digital photography, mostly in New Engl
> 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.
I think built-in macros are often poorly used in C/C++. I would much prefer someone use a sed script/etc called from a makefile. than to build a multi-level macro in C, who's intermediate results are not generally viewable, except at the assembly output. However if you use a macro in make, to produce c code, it will be portable to to all compilers, and you can look at the expanded c code to debug it.
Well, your professor was a very ignorant man who understands little or nothing about modern garbage collection techniques. Just because a system uses GC does not mean it can't make guarentees about latency.
I'm not claiming that Sun's implementation has a good, low-latency GC (it's been a while since I've used Java, so I don't know what they're up to these days) but I do know that the Java specification does not say much about such things. Which is as it should be: the desired GC behavior depends heavily on the platform on which the code is running.
Garbage collection gets a bad reputation due to the seemingly inexhaustible supply of crappy implementations out there in the world (e.g., Perl.)
Oh come on, they put that in because the company is run by lawyers and they wanted to cover their asses. That license clause doesn't mean "you can't use Java in a critical application", it just means "if you do, you can't blame us."
"Warning: coffee may be hot!"
CA Marine got splattered by US pilot1's bombs! /g_friendlyFire 0
CA Marine: Medic!
CA Marine [South of Kabul]: wtf!?!?
US Pilot1 [South of Kabul]: Shit I killed some cannucks!
US Pilot1: Sorry!
US Pilot2 [South-East of Kabul]: Goddamn tker
> Console:
>
Friendly Fire is now off!
US Pilot1 [South of Kabul]: fagg0t
Unable to kick US Pilot1: Option Disabled
Osama Bin Laden: TEAMS FFS!!!
Osama Bin Laden got vaporized by US Pilot2's Daisy Cutter!
Ah yes, if only Afghanistan was like RTCW...
Hate me!
CATS: Thanks for calling Commodore Applications and Tech Support! How may we help you?
Pilot: Uh.. I'm spiralling towards the earth, both my engines are out, and my display has a flashing red box at the top that says, "Guru Meditation #00000004.06660666"
CATS: What is the system model?
Pilot: The F-22 jet.
CATS: REAL AMIGANS RUN ON REAL AMIGA HARDWARE, NOT EMULATORS!
Pilot? *@#*! AmigaOS! I'm switching to QNX!
CATS: Can I interest you in a coupon for $50 off your next Amiga, for $50?
As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.
It quickly becomes a big problem too. Such as do you let some kind of subsystem decide when to collect (and thus complicate timing rules for time-critical apps), or in-line the code into every module? When you start in-lining it you begin to lose the main reason for garbage collection, which is to remove memory management from the programmer's error-prone human nature.
I don't know what the java designers were thinking, but probably it was that real-time precision is a small segment and not the market they were targetting, and thus went with the easier to implement, easier on the programmer style of GC.
Honestly, 'modern' GC's aren't terribly different from the older types except they let you choose when to collect and how long to let it collect for. And every implementation has a way of determining which memory to reclaim which varies from one to another...
-
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 :)
Well, there's what they call the Fork Tailed Doctor Killer, aka the Banana, aka the Bonanza V-tail. Has a bad yaw oscillation problem. Likes to wiggle through the air. However, you can buy a device known as a yaw damper, that will detect this yaw and automatically input ruddervator control to dampen the yaw. Basically it turns the ruddervators into a fly-by-wire system.
The big reason fly-by-wire won't show up at the low and slow level is cost - by the time you tack on all the red tape the intial cost of any such device easily triples.
In theory, it is possible to prove correct behavior for algorithmic systems. In practice, it is just about impossible to prove an algorithmic system of reasonable complexity correct.
Don't believe me? I can almost guarantee you that any non-trivial processor-based system uses interrupts for a variety of events; interrupts, by their very nature, are not predictable. Suddenly your nice tidy proven algorithms have spontaneous changes made to all the global state the system keeps. Oops, time to re-verify based on a timing simulator simulating EVERY combination of times that an interrupt can occur. Yikes.
What you refer too is called the "Cobra Maneuver" and is indeed impressive.. especially when done by the pilot who invented the maneuver, victor pugachev, in his trusty su-27. The russians perfected this maneuver in early 1984 .. its impressive, but its nothign new,.
-GenTimJS
tim@jlc.net
> Also, since most software cannot be returned for refund, even if ridiculously defective...
And of course, even if you could take it back for a refund, you'd just get another copy of the same thing.
The actual choice is almost always between crappy software and no software, which is why people so avidly consume the crappy stuff.
Sheesh, evil *and* a jerk. -- Jade
Hello! It appears you are trying to fire a missile, would you like my assistance?
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
At least Debian would note that package ejection-seat should depend on a package that provides parachute. With Redhat packages you're just as likely to accidently install ejection-seat without parachute.
Hell yeah, mod this guy up! And mod me down while you're at it. Dumbass.
This strikes me as odd. It shouldn't, of course. The US Government is known for all kinds of stuff like this. However, this really sticks out for some reason. It seems an organization that can afford to murder people and design stealth technology can't create a working avionics system? Now, do we even _know_ that this story is accurate? Or is it another attempt at psuedo-reverse propaganda by the US Government? Well, I guess it doesn't matter, but, still...
Perhaps this should be part of Microsoft's Windows Logo program. You don't get the logo if you force the user to reboot for no reason. Maybe Nero doesn't have the logo anyway... not sure.
"Security by obscurity is for" ________________.
Tech Public Policy stuff
It's possible to prove correct behavior for algorithmic systems. Time is explicitly accounted for in most such proofs.
I thought all this "proven correctness" stuff was laid to rest when the "proven correct" software examples in Dijkstra's seminal book on the subject proved to have at least four bugs.
It is not possible to prove that software is "correct". That is because what constitutes "correct" varies with the intent of the software. hello.c is "correct" if the intent was to type "Hello, world!\n" but not if the intent was to display a popup window or play a CD.
What it IS possible to do is to prove two or more distinct expressions of the desired program behavior, one of them the program itself and all of them in formal languages, are equivalent.
But expressing the desired behavior in ANY formal language is the act of writing a program. How do you know that the non-program expressions of the "correct" behavior themselves are "correct", rather than having equivalant bugs?
The answer is that you do it by having the languages be as different as practical and having different people (or teams) write the various versions of the expressions of intent. Then you debug them all together, until they all agree, and all also agree with what the people THOUGHT was right when their attention was brought to the places they initially disagreed.
This works because different people tend to make different mistakes, and different languages tend to lead even the same programmer into making different mistakes. (The former has been known since before automation. It was put to good use in the tab-card era, where one operator would punch the cards on a keypunch, then another would "verify" them by typing the same keystrokes on a similar machine.)
Of course, if you substitute "spec" and/or "comments" for "formal description", and "QA team" for "proof engine" you have the classic team software development process. Substitute "other programmers" for "QA team" and you have the walkthrough. And so on.
= = = =
I agree with the rest of your point, however: Well designed, well tested software can be enormously more reliable than the hardware it runs on. A program is digital. If it is correct, it is ALWAYS correct. It never fails, never makes a mistake, and never wears out.
Bantam Dominique roosters crow a four-note song. Once you've heard it as "Happy BIRTHday" you can't NOT hear it that way
* Windows. I don't need to say it - use your imagination.
* Macintosh. An elegant joy to use, but the only airplane that comes with it is translucent turquoise and shaped like a giant sphere.
* Nokia. Good quality if a bit simplistic, but it works only when you're flying over Europe.
* Amiga. Perfect in every conceivable way, except that it's available for only restored P-39s.
* Sony. Controls are very simple, durable, and easy to use, but the screen can display a maximum of three gauges at a time.
* Palm. You have to replace it every 2,000 miles.
* UNIX. Pros: sophisticated, minimalistic, and rock-stable. Cons: the altitude-reading command is called "qxz" and the HUD is done in ASCII art.
you'd just get another copy of the same thing
Not quite a refund, ain't it?
which is why people so avidly consume the crappy stuff
Which is why people came up with open source.
This post was compiled with `% gec -O`. email me if you need the sources
Really you guys - all of the clues were in the first post. Circle is always the same size, only the tickmarks move. Everyone who said "Breshenham's" gets a D+. Pre-computation of sine & cosine gets an F+.
per call tech support charges or crashed planes.
...///...
It's been final since September 2001.
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
Ja Wohl!
Make that "since November 2001"...sorry it was a brain cramp. ;-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
This post is offtopic, inflammatory, but true.
Truism number 2
Truism number 3
"The only rights you have are the rights you are willing to fight for."
Truism number 4
"The only rights you have are the rights you are willing to fight for."
Ah, undecidable. Forgot to click anonymous? Oh well. So nice to see you again.
;)
I know I must have hit pretty close to the mark in our previous conversation to earn your lasting affections.
We're on the road to Tycho.
Hi Dave,
I just want you to recognize that you own what you say. I'll be bothering you for quite a while, just to remind you.
It's all about Karma, after all.
Perhaps you'll even grow up a little bit. I honestly hope that it doesn't have the opposite affect: making you even more belligerent.
"The only rights you have are the rights you are willing to fight for."
If you have a burning need to make an ass out of yourself, then by all means, don't let me stop you.
:)
Frankly, I feel you'd really be shortchanged if you didn't strive for even higher levels of embarrassment.
Have yourself a ball, cheez whiz.
We're on the road to Tycho.
I think that saying should be attributed to uncle Joe (Stalin) and he said: Every country has an army, its own or someone else. PS I think the Saudis can agree about that nowadays... DS
The pre-process-only option (-E) to the C compiler produces the result of macro expansion.
Welcome to my ignore list. ;)
We're on the road to Tycho.
"Every Neanderthal encampment has a bunch of alpha males in it..."
"Prepare for the worst - hope for the best."