Houston, We Have a Software Problem 331
An anonymous reader writes "The computer system that launches the Space Shuttle is an old, but important, computer system. It is built from mid 70's technology and features SSI chips like 7400's...which are getting hard to find. It has 64k of memory and no room to repair any software bugs. NASA started the CLCS project in 1996 which uses state of the art computer languages, OO methodologies, and hardware. Everything that you could actually hire people off the street for. However, NASA is in a budget crunch with the Space Station cost overruns. It is looking to trim costs to keep the Space Station going. There are stories about CLCS getting cancelled here and these guys say its already cancelled."
It has 64k of memory (Score:3, Funny)
Re:It has 64k of memory (Score:2)
You don't mean the kind that looks like jillions of tiny tires (or black donuts) intersecting with the wires of a chain-link fence, are you?
I thot that ended in the late 60's.
Re:It has 64k of memory (Score:5, Interesting)
Yes, he does mean Core Memory, and yes, the AP-101 as flown in the Shuttle from mid-70s through to mid-90s did indeed use Core memory.
Indeed, the upgrade to the AP-101s with (I think) static-column RAM took so long because Core memory has the lovely property of retaining information even when the power dies - a key factor, sadly, in the ability to retrieve information from Challenger's onboard computers after the 1986 crash. Another key factor is that Core memory is remarkably resilient to bit-flipping caused by cosmic rays and other radiation (events known as "SEUs" or "Single Event Upsets").
All of which meant that it was a major project just to replace that memory with more modern RAM. And it's not just a couple' sticks of SDRAM either - most of the space-savings you'd expect from replacing bulky core with nice compact RAM chips is taken up with additional hardware to a) provide sufficient power support to retain memory in the event of main power failure b) continually scan through memory doing parity checks to detect and correct for SEUs...
Don't diss Core, man...
Re:It has 64k of memory (Score:2)
70's computers seem much more radiation friendly than the newer stuff. It is harder to take advantage of Moores Law on spacecraft due to radiation out there, especially when visiting gas giants like Jupiter that are swarming with radiation. (Not likely the shuttles will be visiting Jupiter anytime soon, though.)
the future? (Score:2, Insightful)
Sorry if the article answers this, I can't get to it.
Re:the future? (Score:2)
Why not simulate it? (Score:3, Insightful)
Re:Why not simulate it? (Score:2)
Also you have to ensure that the simulator has zero bugs, which means simulating the bugs in the original equiptment which their code depends on.
Writing a perfect software simulation of hardware is IMO a job as equally hard as just rewriting the original code.
It's not like they have millions and millions of lines of code, the original rom must to have been less then 64k or so. They just have to rewrite the code in a language that is more maintainable which machine code is not.
Re:Why not simulate it? (Score:5, Insightful)
Now, imagine you take modern commodity hardware (which changes periodically - look at how often Intel silently release new steppings of their CPUs). You're not going to have a guarantee of consistency there. You're going to have to boot an OS off it - and even the simplest RTOSes are still much, much bigger than the whole platform currently. Then you need an emulator. Then you need the system. And the only problem you've solved with all that work is the unavailablility of the old hardware - you still have a old machine language on a tiny platform which can't be easily extended for new functionality.
Re:Why not simulate it? (Score:5, Insightful)
What they have, right there, is one spectacularly reliable piece of software. I suspect it's significantly more bug free than even the microcode in a modern processor, let alone the companion chips, bios, operating system, and virtual machine for some god awful p-code language (not that I'm naming names here).
The question that should have been asked is "how can we make a sustainable process for making extremely reliable control computers?". How to go about cutting custom silicon, tiny os's etc. How to save the happy tax payer hundreds of millions of dollars by reselling these services to people making nuclear power stations, heart pace makers etc. instead of going shopping for big sun boxes.
Oh well, reality strikes again.
Dave
port the software? ... try hardware! (Score:4, Interesting)
Might I suggest using FPGAs [vcc.com] to emulate the hardware old system so the software doesn't have to be thrown out?
Assuming that circuit layouts are available for these old chips, it would be a piece of cake to emulate them in VHDL (a hardware description language) because they are comparatively simple to today's integrated circuits. Once the chip descriptions are written in VHDL, it would be relatively easy to 'port' the hardware over to a new FPGA if the old one dies or whatever. Then it would not be necessary to truly port or re-code any of the currently working code, and it would be much easier to fix bugs and extend it because you don't have the memory and speed limitations of the old system.
Re:port the software? ... try hardware! (Score:5, Interesting)
Despite all this tweaking, the crufty old systems stayed in place. Why? Well, on each of these old boxes, we could support 25-30 journos and the systems just worked, grinding out newspapers day after day.
People kept talking about replacing them, not least because we had to train up operators and engineers on them every time new staff came in, parts were hard to come by (the standards-not-compatible SCSI and ethernet interfaces were picky about what they talked to, and the filesystem could only address 600 MB of disk per system), and they used huge amounts of power and floor space.
For the three years I worked there and in the three years hence no-one has been able to deliver an editorial system that just works. When vendors rolled their rigged demos in, they crash. The major vendors like CyberGraphics and ATEX couldn't point to successful implementations of their new systems producing a decent number of newspapers on the basis of more than one edition per day.
Would it have been nice to have a Unix or Windows based system? Sure. Reduced overheads and training burdens, able to buy the latest and greatest hardware, and so on. But no-one could actually deliver something that worked better than the crufty old J11 systems.
NASA are probably in a similar bind; it's a very familiar problem: old systems developed by tight, focused, skilled teams and developed over the years are very, very hard to replace.
Re:Why not simulate it? (Score:2)
The 7400's and such are just interface hardware; that logic, as well as replacement for the 64k ram, etc., could all be put on a single reliable chip (no I386, no heavy OS, no emulator).
There's got to be an only-slightly-more-complicated and nearly-as-reliable by not being too ambitious with the latest tech.
Re:Why not simulate it? (Score:2)
When dealing with shuttles and the like, K.I.S.S. should be the mandate. Ain't nuttin' complicated about a 6809 mobo, yet it can be coupled with an MMU to provide upwards of 1Mb of memory, and there are excellent realtime, multitasking OSes available... with source, IIRC (OS-9, from Microware; and I think there's a QNX for it, too. Plus [ooooh, he stretches his memory...] Flex-09?).
Re:Why not simulate it? (Score:2)
With these considerations in mind, clearly simulating an old computer is a very backwards idea. bug-for-bug compatibility [tuxedo.org] is not a positive effect.
Re:Why not simulate it? (Score:3, Informative)
Besides, the use of modern programming buzzwords implemented by college kids sounds like the principal problem with this project...
Re:Why not simulate it? (Score:2)
Re:Why not simulate it? (Score:5, Interesting)
Exactly. And that includes the shuttle. It has never lived up to what it was envisioned to be and it is only going to become more costly and more failure prone in the future as every bit of hardware on that pig is already showing signs of fatigue.
There are many launch systems that cost far less per pound to throw things into orbit. The reasons we still have those monstrosities flying are political only, not technological or scientific.
Sure this is flamebate. (Gosh, getting rid of the old karma system is so LIBERATING!) But if we can discuss how some little bits of hardware in the shuttle are past their time, why can't we discuss the big bit?
Re:Why not simulate it? (Score:2)
Few, if any, expendable boosters have the lift capacity of the shuttle, so I'm skeptical abut your claim that "anything would be cheaper. But that's a quibble. More importantly, in the two decades that the shuttle has been flying, no one -- government or private -- has made a serious effort to design, build and launch boosters large enough to dramatically reduce cost-to-orbit. The technology is there; it has been there since the 1960's. What's keeping this from happening? Timidity and lack of political will. The "Final Frontier" is in the hands of bureaucrats and corporate execs who can't see beyond the next commo satellite launch. It's as if the only reason to move into space is to make our damn cell phones work.
Re:Why not simulate it? (Score:2)
Not for long. Robotics is getting better and cheaper faster than space tech + expensive humans. It's only a few millisecs of latency for telepresence, until AI can do the job locally (much later).
Do you really think that private enterprise is going to terraform other planets?
Terraforming? How quaint. Extrapolating tech into the future indicates we'll sooner be taking the planets apart for raw molecular building material than wasting space & material & escape velocity energy, by living on the tiny surface area of another gravity well.
Can you come up with a better way to get humans into space (and bring them back if needed)?
Yeah. Divert a larger chunk of the money that would be wasted on chemical rockets and deadweight NASA beaurocrats into nanotech research so we can bootstrap ourselves off this planet much much earlier.
--
Re:Why not simulate it? (Score:3, Insightful)
Huh ? at what frequency regimes ? what about X-rays ? IR ? UV ?
besides, the atmosphere does distort image even for visible-light imagery. It is true that advances in image-fixing algorithms made, AFAIK, in the last decade attenuate the problem to a large degree, but, AFAIK, there was nothing like that in the seventies, and nothing is better than eliminating the problem altogether anyway.
perhaps today it will better to build bigger telescopes on earth than launch them (again, for the visible light regime. I very much doubt this is true for X, UV or IR imagery
saying such a large project, with published scientific results, is "just PR" with no references to back up your claim seems like slander to me.
I wouldn't be amazed if somebody told me they fitted the broken mirror on purpose so they could go and fix it with the shuttle...
I wouldn't be amazed by a lot of things, but I don't ususally go slandering hard-working people just based on what I suspect they are capable of doing.
The US space program and NASA deserve (and get) a lot of criticism, much of it is quite pejorative, much of it is technically sound. I haven't seen any such thing in your post, which is IMHO just nasty unbased negative PR
Re:Why not simulate it? (Score:2)
Re:Why not simulate it? (Score:2, Informative)
You can't just buy a system from Dell and put it into the Space Shuttle. You can't use a Pentium, a modern hard drive, Linux, Windows, or Open Source anything.
As far as the hardware goes, everything mission-critical that goes aboard the Shuttle has to be ruggedize against incredible vibration, tested a thousand different ways to make sure that it can't be affected by exposure to vacuum/heat/cold/radiation/cosmic rays/etc., tested another thousand ways to make sure it doesn't interfere with other critical Shuttle systems... and on and on.
And a bug in the newly written software could cause not only the death of several astronauts, but potentially the loss of a Shuttle, a launch facility, and the ISS. Would you, under any circumstances, put your life, five other lives, and billions of dollars in the hands of software that you found in an Open Source project?
On your desk a "Fatal Error" isn't, really. But 60 miles up?
Re:Why not simulate it? (Score:3, Interesting)
Re:Why not simulate it? (Score:2)
There hasn't been a front page story of a shuttle launch for as long as I can remember, and even TV stations don't broadcast it like they used to do in the 80s.
Besides, the space program is not, at this point, existing in a vital capacity for our nation. There are no weapons platforms orbiting the earth. There are no survillance photographs. Hell, there isn't even a space tourism project run by the United States or a U.S. corporation -- the Russian government does that!
The Russian equipment is good enough to get people up and back safely -- and they're not above taking millions of dollars to let someone else experience it. The U.S. seems to have a hissy fit when they suggest it -- NASA is about "science" not "entertainment."
The nation's (and the law makers and budget appropriators) backwards views on the space program in general need to change, and before any type of a hardware change. It needs to be retasked to be under the Department of Defense, or outsourced to the public sector. Private companies build satellites that work right. Why can't they build the launch platform and send people up, too?
Re:Why not simulate it? (Score:2)
Or you could just... (Score:4, Funny)
Re:Or you could just... (Score:2)
Re:Or you could just... (Score:2)
Common Problem (Score:2)
Stephen
Re:Common Problem (Score:2, Interesting)
FYI: That extra bump in memory allowed us to store the entire Entry program in upper memory so that in the event of a Trans-Atlantic abort, we wouldn't have to wait 20 seconds for it to load from the mass memory.
Re:Common Problem (Score:2)
Which is why serious software engineering is done on platforms like the SPARC, where you can guarantee that later CPUs can run earlier code, or on IBM operating systems where everything is a virtual amchine anyway.
Re:Common Problem (Score:2)
7400s hard to find? (Score:5, Informative)
Certainly the 7400 series as a whole is still widespread and used in hobbyists kits, I'm not that old. Maybe the original 7400 is becoming obsolete, being replaced with the 74LS (low-power Schottkey) or CMOS chips? If then it shouldn't be too difficult to replace the TTL logic with CMOS logic, given a few adjustment levels in voltage, or they could use the TTL-logic and CMOS-logic in one compatible chips [cjb.net].
Of course, the 5400 series SSIs (small-scale integrated circuits) are preferred over the 7400s for industrial purposes, and as a plus they are completely backwards compatible. Why isn't NASA using those?
Re:7400s hard to find? (Score:2)
Given the above, I still don't see why they would not reimplement the whole thing in a slightly newer logic family and requalify it.
Re:7400s hard to find? (Score:5, Interesting)
The 54 series parts were like the 74 series, but in a hermitically sealed case, 100% tested over a wider temperature range, and burned in to remove infant failures. For this application they used space qualified components. The same as 54 series parts, more stringent tests, and now the chips are also evaluated for radiation resistance. Any change in the design or production process and the 54 & space qualified chips must be requalified. What can happen is that a chip is produced to be fuctionally the same, but using smaller geometries, and now is more suseptiple to ESD and radiation.
CMOS chips, because of their high impedances, are notorious for ESD and rad sensitivity so they won't do.
With the reduction in military, aerospace, and space spending many manufacturers have dropped the 54 series and space qualified components. They haven't made any attempts to add replacements in their product lines.
When a part is dropped, the manufacturer usually informs the industry of their intent. You're given a date & price for a final order. the theory is that you can buy a lifetime supply of these parts. Industry isn't likely to but any more than they need to complete existing contracts plus a few spares, there's no guarenty that you'll get any more contracts to build items requiring these parts so these purchases will cut into your profits. Government procurment may buy additional components, but lack funding to really buy large quantities.
An opportunity is presented, and they will be taken advantage of. A distributer might buy some additional parts -- since the distribributer has several customers buying a particular part from him, his risk of being stuck with an unseable component is small.
After the final production run, the chip manufactorers will sell the documentation, tooling, and rights to make a chip. There are small manufacturers who buy these, all well as the out of date machinery to produce these parts. They can then make small production runs, sometimes under a hundred components, for a price. In addition, they might buy untested dice or wafers from the last production run. The untested & unpackaged componets are very cheap, so it's more affordable & less risky to buy and store these than the completed components.
So it is possible to still get the parts needed? -- at a price!
Re:7400s hard to find? (Score:3, Informative)
- When I plugged one in backwards I just went down to my local Radio Shack and picked up a new 74LS00
Dunno about the Shuttle, but I assume my experience applies. I used to write autopilot & autostabilser software for helicopters. They used 80286 & 68000 CPUs, which have started to become more difficult to find. Not because there are no 286's or 68K's out there, but because there aren't so many 286's and 68K's available that are certified for flight.Re:7400s hard to find? (Score:2)
How much of that is bureaucracy at work, and how much is technical?
Re:7400s hard to find? (Score:2)
Remind me not to fly on any plane that you worked on the avionics for. There are times when overwhelming paranoia is an asset. When your Playstation crashes you can always start a new game. When your main engines get told to hardover on launch because of a failed chip, you die.
Re:7400s hard to find? (Score:2)
Re:7400s hard to find? (Score:2)
I'm sure we could have gotten faster chips rated for space, but we were on a tight budget, so the 386 was it. :)
Hey, O'Keefe, look what I found on SourceForge... (Score:5, Funny)
"shuttle_launcher_0_1"
Excellent. That'll save a few dollars. What's the development status?
"1 - Planning, sir"
Ah.
A Simple Solution (Score:5, Funny)
(2) Break down the old mainframes until you have roughly 50,000 pieces...
(3) Sell it on eBay (or other auction sites) as space memorabilia, mention that the computer the parts came from were responsible for guiding the Apollo missions to the moon, etc and so on... The machines are SO obsolete now that the only way they could pose a security risk is by sending them back in time...
(4) Profit!
(5) Buy a nice little beowulf cluster, hire 20 Linux geeks and feed each of them $50 in dew and pizza in exchange for setting up the system...
(6) Use remaining funds to pay the Russian space agency to have a little "airlock accident" for that Nsync guy...
Re:A Simple Solution (Score:4, Funny)
[Lance] Bass, of the pop group 'N Sync, had been training at the Star City cosmonaut complex outside Moscow; he was told today to pack his gear and leave after "failing to fulfill the conditions of his contract," a spokesman for the space agency told Reuters.
Adding insult to injury, the space agency said Mr. Bass, 23, would be replaced on the October mission by a cargo container.
Re:A Simple Solution (Score:2)
They need to change the horse not the jockey (Score:5, Insightful)
In fact, the Saturn V was able to launch 4x as much for about the same cost. It could probably have launched most of an ISS in a single launch, and tacked on more sections in 2 or 3 more launches.
Re:They need to change the horse not the jockey (Score:5, Interesting)
In fact, the Saturn V was able to launch 4x as much for about the same cost. It could probably have launched most of an ISS in a single launch, and tacked on more sections in 2 or 3 more launches.
Here's where you lose on your argument. The manned vehicle compartments that were available to the Saturn V made extra-vehicular activities very difficult. The Shuttle has a much better design for short-term laboratory work, for crane work, and for extra-vehicular work. You could dump all the parts for an ISS into orbit with a few Saturn V trips, but you couldn't work with those parts to assemble them. In fact, you'd have to drop the parts a fair distance away and then find some way to bring them closer to the building orbit location. You wouldn't want to chance using NASA's equivalent of a Greyhound Bus to maneuver anywhere near the multi-billion dollar parts (and stationed lives) that may already be on-site.
Re:They need to change the horse not the jockey (Score:2)
It seems there are much easier ways around that issue than to design something as costly as the shuttle.
You wouldn't want to chance using NASA's equivalent of a Greyhound Bus to maneuver anywhere near the multi-billion dollar parts (and stationed lives) that may already be on-site.
To use your analogy, then you have the Greyhound bus tow a little delivery vehicle, rather than trying to turn the Greyhound bus into something that can both carry lots of cargo and maneuver like a forklift.
Correction... (Score:2, Interesting)
I had nothing to do with the failed coup, for the record.
Re:Correction... (Score:2, Informative)
The Russians *have* shuttles, but they never used them beyond tests.
Buran -- Russian for snowstorm -- is the name of the Russian shuttle that made one unmanned spaceflight in November 1988.
It circled Earth twice, landed automatically and since then has sat in storage at the Baikonur Cosmodrome in Kazakhstan. On May 12 the vehicle was damaged by falling debris when portions of the roof of the building the Buran was in collapsed.
Several other copies of the Russian shuttle were built as part of a test program and through the years have all become known by the name Buran.
Of those, one Buran was turned into a space-themed restaurant at Gorky Park in Moscow and another was given a fresh coat of paint before going on display for more than a year in Sydney, Australia during the time of the 2000 Summer Olympic Games.
(from a Space.com article [space.com])
IIRC, they swiped the design from the US shuttle, and made some... odd modifications like leaving out the main engines.
Re:Correction... (Score:2)
The Space Shuttle main engines are taken out, torn down and rebuilt after every flight. I don't believe this to be very cost effective.
One point that is missed is that it costs much less to mass-produce engines, the Space Shuttle main engines are one-offs, and hence are very expensive to start with. The Russian approach is to reduce costs via mass production. I believe that this is a sensible approach right now. Only if the launch rate is high enough is reusability going to win.
Oh come ON guys!!! (Score:5, Funny)
Oh, wait....
Re:Oh come ON guys!!! (Score:2)
Re:Oh come ON guys!!! (Score:2)
This is how you launch the shuttle (Score:2)
LOAD "NASASHUTTLE",8,1
Re:This is how you launch the shuttle (Score:3, Funny)
My Apple II, on the other hand, you just insert the disk and flip the power, and the NASASHUTTLE program comes up automatically, in 1/10th the time your C= disk drive loads it!
Of course, your version has better sound, and sprite graphics... but oh well.
Space-Station cost overruns (Score:4, Insightful)
Just what is the space station actually for?
The money spent on this (and the space shuttle) could be spent on real science and could get a thousand off-the-shelf spaceprobes to interesting places.
I suppose getting rid of Lance Bass would have made it worthwhile, but even that's not going to happen anymore (unless /.ers constribute to a paypal account for this purpose...)
roses are red
violets are blue
the Russians have satellite laser weapons
so why can't we too?
More shuttle development? (Score:5, Insightful)
I'm not one to replace things that are working fine, but as I understand it, newer designs could be a whole lot cheaper to operate. So I wonder if pouring more into the Space Shuttle program is the best thing to do.
I'm not saying "let's throw out the space shuttle" but it bothers me that there's apparently nothing in the works with a decent shot at replacing it any time soon. It seems the field of space exploration is becoming antiquated.
Re:More shuttle development? (Score:2)
Re:More shuttle development? (Score:2)
The computers didn't work right for that too
Easy solution (Score:3, Funny)
The guy's so good he may do a better job than a bloated team of 400 contractors.
Re:Easy solution (Score:2)
John Carmack might be a kick-arse game programmer and a very smart guy, but he is not an expert compiler designer, complexity theorist, or, as is most relevant here, embedded systems programmer for safety-critical systems (though I'm sure he's rapidly learning about it with his rocketry hobby).
7400? (Score:2)
Re:7400? (Score:2)
Space Computing: Some Numbers (Score:5, Informative)
From an article in the Sydney Morning Herald [smh.com.au].
The software is built in a similar way - lots of internal checks, tell-me-thrice memory, soft-failure-bit-flip-correcting daemons etc. In this case, lives aren't at stake, but the people doing the programming are used to situations where they are.
Maybe not lives, but lots of money (Score:2)
Not only that, a single space launch of even a fairly small satellite still costs over a billion dollars. If there's a software glitch, it could render the satellite totally inoperable, and I doubt that these engineers want to tell their source of funding that a glitch they're responsible for just wasted the whole launch...
Which is also why Microsoft doesn't do aerospace embedded systems. :) Whoops, Satellite Redmond I just had a BSOD...
Re:Maybe not lives, but lots of money (Score:2)
We're getting a free ride along with the ADEOS II [nasda.go.jp] megasat (the Japanese get access to some of the data in return), but we're still talking significant money for development. And you're right re funding: it's no exaggeration to say that the future of Australia's space programme is at stake.
As regards Microsoft doing space/embedded systems, another quote from the original article [smh.com.au]:
A neat quote, even if I say so myself.A. Brain, Rocket Scientist
using GNU software, too (Score:3, Insightful)
Re:using GNU software, too (Score:3, Informative)
You're correct, GNAT 3.13p. Anyone with mod points, please give this guy one for "Good Deduction"
Re:Space Computing: Some Numbers (Score:5, Informative)
The context was that of software for an unmanned microsatellite, not the shuttle.
Crewed spacecraft have an even more strict set of rules attached to the software development process. Have a look at some of the articles [af.mil] on DO-178B [lynuxworks.com], the software development standard for avionics. Similar issues apply, but even more so.
Look, people - not Geniuses - just normal, everyday programmers - have been making software you can bet your life on [adaic.com] for a long time now. We know how to do it even more cheaply [af.mil] than the normal buggy commercial work (though testing is radically expensive and blows out the total cost). There's no need, and no excuse, for BSDs and security problems. None. You just have to have the right tools, the right training, and the right attitude. If you like, the Right Stuff [fastcompany.com]. Here's a quote from that article:
People like myself look upon any work over about 7 hours a day more than twice a month as signs that "I personally screwed up", because I'm the guy who sets the schedule, not some PHB. We have lives. We have kids. We have hobbies. And the stuff we do is hard, the systems do a lot more than most commercial apps, and with far fewer memory and CPU resources. It's both incredible fun "boldly going.." and all that, but also a crushing responsibility when we do safety-critical work. People's lives depend on us doing the best possible job we can.One area I disagree with in the "Right Stuff" article is that the work doesn't involve creativity. This is balderdash - we're doing stuff no-one has ever done before under really tight resource constraints. To get a reliable architecture often requires significant smarts, lateral thinking. Anyone can make a complex solution to a complex problem, the really good guys and gals make solutions so drop-dead simple, obviously-correct and efficient that it's miraculous how much such simple, obvious and readable code actually accomplishes.
Looking at the general world of InfoTech, we see that most programmers out there would rather write the winning entry for the "Obfuscated C" contest than make some software that gets us around the solar system. And that people who make reliable software hit the unemployment queue on project completion, while those making buggy stuff have jobs-for-life in maintenance. Of course, they often have 80-hour weeks too, and are driven by PHBs who know b* all, and can't even take pride in the product, so there is some justice.
A cheap $150 solution (Score:2)
400 Contractors??? (Score:2)
The only reliable piece of the Shuttle (Score:2, Informative)
The only exception was the computer systems group, in particular the software side. They had metrics, procedures and rigour.At the time of the enquiry the hardware was already old.
It's the attitude that counts, not the hardware, not the methodology of the month. OO is not going to solve NASA's problem, it's going to be difficult. Myself I'd just make sure that the hardware would always be available, and not change a thing.
use a verified virtual machine and compiler (Score:3, Insightful)
They obviously don't need very high performance, since it runs on 1970s hardware, but they do need high reliability and low development costs.
That means that they should be using a safe, secure high-level language. Something with a virtual machine might be a good idea so that it will be easy to adapt to new hardware platforms: you verify the virtual machine on the new machine and then have reasonable confidence that your code runs.
If they want something in widespread use, a home-built Java byte-code interpreter (not a JIT--they are too buggy) might be a reasonable choice--it's well specified and there are lots of people who know how to program it. They should probably avoid JNI like the plague and instead add new bytecodes for I/O and communications and verify them the same way that they do the virtual machine itself.. VLISP [nec.com] might be another good choice--or at least a source of ideas for how to implement a verified Java interpreter--DARPA already has paid for its development.
And they should hire someone who doesn't recommed COTS with C++, lest we see the next shuttle go up in flames again.
Re: A question for rocket scientists (Score:2)
this raizes an interesting question: how much better would a rocket with fast-response feedback mechanisms be ?
and what are the time-scales involved ?
how much can you raize efficiency and reliability (automated problem detection and solving) with better computing ?
would a "real-time" (at the time-scales involved) automated simulation and analysis of the machinery involved (using inputs from the hardware) be beneficial at all ? how ?
Re:use a verified virtual machine and compiler (Score:2)
Indeed. So where does this rubbish about Java bytecode come from? You're already going to have to verify the processor and the compiler output. Why introduce a third level (a VM) where things can go wrong?
That was just a gratuitous and offensive swipe. The Challenger shuttle went up due to mechanical problems, not software bugs.
You seem to be one of those people who doesn't like C++, and therefore lumps it together with C and/or has a dig at it whenever possible. It's up to you whether you like a language or not, but please spare the rest of us the ill-informed language wars, OK?
Good Idea, But Java is TOO complex, Use FORTH (Score:2)
Re:use a verified virtual machine and compiler (Score:2)
Don't confuse "not needing a processor that wastes millions of cycles a second" with "low" performance.
Then need to work with very percse units of time, and have a exceptionally high success rate, fault tolerant and correcting, minimal suseptability to SUEs. The is high performance, as far as industry is concerned.
Re:use a verified virtual machine and compiler (Score:2)
And if you stay in the business for many more years, you'll realize the hubris and folly of that statement.
The myth that C/C++ is difficult
I made no statement to the effect of whether C/C++ is hard or not. I actually think C is a pretty easy language to learn. But it can be hard to write reliable software in otherwise easy languages, and it can be hard to verify compilers for easy languages.
In fact, C++ is one of the most difficult languages to verify a compiler for, and I have personally tracked down a number of bugs in both commercial and open source compilers. The fact that C++ compilers are hard to verify alone would be a reason not to use the language on critical tasks, even all other issues aside.
Re:use a verified virtual machine and compiler (Score:2)
Given that you are so brilliant, go work for Microsoft or Netscape or any of a number of big companies, who evidently lack the "proper technique and rigour" to produce reliable software. If it's so easy, you should be able to fix their numerous bugs and problems in no time.
Degrees of reliability (Score:2)
That really depends on your definition of reliability. If you're talking about things like buffer overflows and memory leaks, then yes, good basic programming technique in C++ makes it a far more powerful tool than most give it credit for. OTOH, C++ compilers are complex and buggy, and the imperative rather than declarative nature of the language makes verification of algorithms much harder than it might be. There is still plenty of scope for unreliable C++, on the scales we're talking about here.
In a case like this, you could well afford to go for a more advanced language and make sure you've got a well-trained development team and a verified compiler. The programming world has better tools than C++ available, but pragmatism puts them beyond mainstream use for the time being, which is why C++ remains such a useful tool. In this case, though, you have both the resoures and the motivation to use better.
NASA == Smithsonian (Score:2)
I used to work for GSFC (Goddard Space Flight Center). It was wonderful... many years ago.
Anywho... they had *shitloads of unbelievable equipment... ages old... *name that piece of hardware*. We could wander from building to building, and look/view/see the equipment.
Lots were there because they were running projects that took many many years to see results, thus they could not upgrade *in-the-field* because it would stop the project.
Indeed, part of GSFC when I was there was to backup Houston on launches. When they upgraded they built a totally new floor above the existing backup, and on a *grand* day they transfered power, with one big switch, from one floor to the next - why? because they had to. It had to be well tested and well checked before it could be put in live production, yet the existing systems had to be on-line to backup Houston.
It was fantastic walking through the various buildings and rooms... I've seen equipment I've no idea what it did. For example, one room had these rather large, circular platforms with clear plastic or glass domes. Inside the domes where flat plates - think silicon... but BIG.. 1 1/2 ft octogon. Stacked with about 2 inches spacing, about 10 of them. I'd say, looking at the room, some very old old old type of RAM.
That's the wonder of NASA :)
Nooooo kidding.! (Score:2)
"State of the Art" is a good way to run your pocket book into the ground. Jumping on the newest, fanciest programming language doesn't usually make a business successful.
Here's yet another example: My company's (former) largest competitor invested *millions* into Sun hardware and development in Java. Why? "State of the Art". And guess what! With all of their "state of the art" infrastructure, their system was still slow as molasses.
What did we do? We spent less than a tenth of what they did to develop with Perl on x86 servers. Our site handles huge traffic loads pretty effectively, and we did it without running ourselves to the bankruptcy court.
steve
There's a separate avionics upgrade (Score:2)
NASA is currently struggling with obtaining a reasonably modern rad-hard CPU. The market is so dinky that nobody wants to bother with it. But they have been able to retrofit flat panel displays, at least.
Recruit volunteers! (Score:2)
Perhaps the crew at, say, ham radio organizations like AMSAT, [amsat.org] or other groups that already combine volunteer engineering effort with an interest in space exploration, would be happy to help out with modernizing the systems. I wonder if anyone's asked them?
NASA would, of course, keep enough engineering staff around to check the improvements out, but why limit themselves to paid labor if the resource to pay is drying up?
Best being the enemy of the good, again (Score:2)
It strikes me that this is exactly the sort of project where you don't want to attempt to construct an ambitious, all-singing, all-dancing, state of the art, eighth wonder of the world. This misses the point about what is actually needed. Instead, you go for something as simple and straightforward as you can design which will have the capacity to do the job and continue doing the job for the forseeable future. It needs to be simple so that you can analyse its behaviour and failure modes with a high degree of confidence. You can push the sexy bells and whistles out to helper boxes, but the core systems must 'just work'. And technology that's far enough behind the bleeding edge for its characteristics to be well understood is definitely a Good Thing in these situations.
Remember the old engineering rule of thumb: "when in doubt, make it stout, out of things you know about".
Re:Scope creep! (Score:2)
Actually... (Re:They should make it open source) (Score:3, Interesting)
Think of who space enthusiasts are and what a lot of them do; software and hardware development. In a budget crunch a good strategy would be to allow interested hobbyists to write some of the code, and then have NASA's boys peer review it.
Re:Actually... (Re:They should make it open source (Score:2)
On the other hand trying to see it from you average government official's point of view, there would be paranoia since, I believe, NASA shares technology with the military and even without the mililtary ties, there would still be fear mungering over 'national security'. Also, your average programmer probably wouldn't have access to the hardware to run and test the stuff on.
Re:state of the art? (Score:2)
OO languages' authors may feel that they are doing something more "advanced" but in fact they are working on a completely ortogonal area of development. And most of them are far from C elegance (ex: Stroustrup doesn't even understand C design properly, so C++ is even more inconsistent than what its origin would suggest, and I don't even consider a rotting pile of shit that its "standard" libraty is, to be a part of language), or are simply badly designed (ex: Java), or are not languages but eclectic messes made by including specific librariers' and object models design into the language itself (ex: C#).
This is the area where we can use a lot of progress until it will reach the state where we can keep call the same thing "state of the art" for 30 years, but I won't hold my breath -- OO language design is dead, everyone is just making "OO" languages as various vehicles to promote their narrow-minded ideas. So I won't be surprised if Stroustrup's mess will remain the most useful semi-OO language for the next 30 years, too (but those libraries HAVE TO GO, and so should the attitude that students should learn that atrocity without studying C first).
Re:too much waste (Score:3, Interesting)
NASA falls under the classification of "independent agency" within the Federal government. The budget is hooked up with other agencies such as the Vetran's Administration if that tell you anything about how things are considered.
Re:OO?!!!!! (Score:2)
Re:OO?!!!!! (Score:2)
Amen Brotha!
oop.ismad.com
Functional programming? (Score:2)
Um... Functional programming might be a much more appropriate tool for this job than any OO language I know. And I program C++ for a living. :-)
Re:This demonstrates the trend (Score:3, Interesting)
It's not so much an issue of bloated code as it is an attempt to cover all the bases. The shuttle software was designed with one purpose in mind -- get that shit-heap into orbit. You can't compare it to a modern Linux distro without invoking an apples-to-oranges counter-argument.
Furthermore, the launch of the shuttle isn't handled by a single onboard computer. It's handled by several. Please reference The Space Shuttle Operator's Manual [amazon.com] for more on the systems aboard the shuttle. It's a general, non-technical overview, but a great reference, nonetheless.
You ask "where will it stop?" Here's a hint: it won't. And this same argument probably came up in the 1970's when they started writing the spec for the shuttle. The computer aboard the shuttle is more capable than Apollo for a mission profile that isn't significantly more difficult in any regard (generally speaking). Hell, the PDA you have sitting on your desktop right now has far more computing power than all the computers involved in the Apollo program put together, and it certainly doesn't do anything like putting men on the moon.
But again, it's all a matter of the scope of usage.
80's technology was the best (Score:3, Informative)
In the 80s the microcontroller technology was just good enough to embed a processor with 64k of ROM full of finely crafted code written by a single programmer and it always just worked, perfectly, every time.
Still going strong in the '90s and post-2000 (Score:2)
What was "state of the art" in the '80s is now ubiquitous and hidden from the end user.
Ever found a bug in your portable Nomad MP3 player (The flash-based ones, not any of the disk-based ones - Although the disk ones are still pretty strong)
Has your car ever shut down because its computer crashed? (Note: Hardware failure doesn't count, although automotive ECU failure is RARE unless you've done something to screw with its cooling.)
What about your VCR?
These are all cases of coding like you described - Fitting as much as possible into as little space as possible. In Lucent's (now Avaya) business communications division, there was (maybe still is) a raging debate on whether the usability benefits of using two LEDs rather than one justified the *pennies* of extra cost on an item that sold for a few hundred dollars. In a cost-cutting environment that intensive, you're not going to spec a processor with 8k of flash and 2k RAM when a processor with 2k/256 bytes will do. (Note - Popular microcontroller such as the Atmel AVR, Microchip PIC, Motorola 68HC11, etc. all are in this range.)
And it's quite easy for a single programmer to do all of this. I've seen CD-based MP3 players developed in a few weeks by a team of two college students for their Microcontrollers course taking 3-4 other classes at the same time.
Re:Still going strong in the '90s and post-2000 (Score:2)
What I see very well is products that don't satisfy their intended audience because their embedded software sucks. This is happening more often than 12 years ago.
Why is this happening? My guess is that since the hardware is much more powerful engineers are tempted to try to do much more in each product. The problem is that quality software development management hasn't caught up with the increase in hardware capacity.
In other words, engineers have lost the ability to think simple.
What was "state of the art" in the '80s is now ubiquitous and hidden from the end user.
It's apparently so well hidden that it does not affect overall customer satisfaction.
Has your car ever shut down because its computer crashed?
No, but it has been doing really wierd things with the idle RPMs on cold start and in five visits to the garage the mechanic has never been able to pinpoint the problem. Resetting the computer helps for while, though.
These are all cases of coding like you described - Fitting as much as possible into as little space as possible.
Sure there are, but there are also many cases where an embedded device gets a 32 bit RISC cpu with a few megabytes of flash ROM, a few hundred ks of RAM, a realtime operating system, multiple threads, multiple programmers, bloatware, bugs, endlessly stretching schedules, etc when a 8 bit micro with 32k of of ROM would have been enough..
Re:make it an open source "CALLING ALL GEEKS!" pro (Score:2)
Re:The write stuff? (Score:2)
The worrying thing is that with their expertise, they could have known that this would happen. The appropriate thing to do would have been pilot projects followed by more ambitious projects. Now they've bet everything on one horse and are left empty handed. What they had before they started was a piece of shit (presumably that was why they wanted to get rid of it), and now they have to face maintaining that piece of shit again.
It may have been an elegant system when it was first designed. However by now it has probably seen countless adaptations, comes with thousands of pages of documented changes (they are control freaks) and probably is very hard to understand and maintain. Likely many of its original designers are deceased or retired by now.
The decision to cancel the project appears to be a panic reaction by management. What they will soon find out is that their old stuff no longer can be modified cost effectively to new requirements. Replacing it will easily take half a decade if you start from scratch and they have just thrown away the efforts of half a decade of development.