Post #137,724
1/25/04 9:00:18 PM
|
Spirit flash RAM functional, error thought to be software
[link|http://marsrovers.jpl.nasa.gov/newsroom/pressreleases/20040125c.html|http://marsrovers.jp...es/20040125c.html]
I'll bet my constructors that this is C++ problem!
DAMN software! DAMN IT! 30 damn years to get SOMETHING right and the same piss-poor answers, over and fucking over, again and again and again.
-drl
|
Post #137,769
1/26/04 8:03:48 AM
|
WOW
And I bet it was coded by a female too.
Get a grip. You can write crappy code in any language. You can write good code in any language. Well, maybe not pascal, but generally speaking...
According to an article that was linked here some time ago, NASA has very rigorous coding standards. It looks like a lot of their problems come from not thinking through the high level elements and keeping track of details (miles vs km, for example.)
Settle down... this isn't good for you blood pressure.
|
Post #137,770
1/26/04 8:07:41 AM
|
WOW
The Apollo and Shuttle computers were extremely limited in capability, and were coded before "standards" and "methodologies" were in place. They never experienced a significant failure. They were sometimes patched in place during the mission. Tell me that 40 years of pointy heads meddling with the programming profession have helped.
-drl
|
Post #137,775
1/26/04 8:49:25 AM
|
Programming for the shuttle
was indeed done after methodologies were in place. In fact, the methodologies used were in use a LONG time ago. I read an article which included code snippets, and included the spec argumentation right along with it in the form of comments. In fact, comments outweighed the actual code by a significant amount.
The problem with coding like this is that it's extremely expensive. My guess would be that they DIDN'T actually follow this methodology, and went with something less rigourous, like extreme programming in the interests of cutting costs. Extreme programming looks quite good, and can make very reliable code, but it's a matter of weighing cost and benefit; when the code is operating millions of miles away, it makes sense to blow the extra dough to go with the ultimate in code rigour, and that means justifying every line in terms of its goal, interface, and environment.
... can you tell I took software specs last term?:)
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #137,777
1/26/04 8:56:55 AM
|
Re: Programming for the shuttle
Consider ADA - well, don't :)
I tend to think that programming worked in these cases because 1) there was no room for bullshitting 2) there was a very specific problem to solve. Problems crop up when real problems get bent around abstract idioms. Limitless hardware leads to use of self-bullshitting ideas that compromise real solutions.
-drl
|
Post #137,779
1/26/04 9:02:52 AM
|
Well, I have to admit
I'd both expect and be surprised to discover that they used and off-the-shelf system for the probe. Expect because it's dumb, and be surprised for the same reason. You'd think that for something like that, they'd want to make sure that key parts of the system were coded to the metal to ensure 100% software reliability... as it's been said before, it's not like you can send a chip monkey there to press the reset button.
--\n-------------------------------------------------------------------\n* Jack Troughton jake at consultron.ca *\n* [link|http://consultron.ca|http://consultron.ca] [link|irc://irc.ecomstation.ca|irc://irc.ecomstation.ca] *\n* Kingston Ontario Canada [link|news://news.consultron.ca|news://news.consultron.ca] *\n-------------------------------------------------------------------
|
Post #137,781
1/26/04 9:15:54 AM
|
Re: Well, I have to admit
Well, I hear stories from my buddy at Langley...
The same person once told me that a civil engineering code he was given, had PI hard-coded as 22/7. It took weeks to discover why the program was giving bad results - they finally called him in to look at the code as a mathematician and he discovered the problem in 15 minutes. Such stories do not inspire confidence.
The Apollo computer had an interrupt driven, real time OS that worked in a few K of RAM and some 30 K of ROM. For these one-shot projects, clearly the best thing is to directly code the software to the problem and the hardware. The very idea of someone going "we're going to code our deal in VxWorks!" just seems to PHBish for comfort. This isn't a cellphone or a car computer.
-drl
|
Post #137,806
1/26/04 11:23:22 AM
|
Do you know what VxWorks is used for Ross?
VxWorks is used in a significant amount of Embedded Appliances.
Heart Monitors, Smart Dishwashers, Fancy Car Stereos, even Car Control Computers, Shavers, among other things.
VxWorks is quite mature and Reliable. It is/was designed to do certain things to make sure it can "work".
Lotsa failsafe options are available for it. Maybe not what the Team @ NASA used though. As others have said it doesn't take a genius to code software... but it surely can't hurt.
You can write bad code in Basic, Shell, Fortran, COBOL, C++, ADA, ASM, Assembly, Java... etc. But you can also write Great Code in those same languages. (Great is a relative term here, given the previous :-)
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
"Lately, The only thing keeping me from being a
Serial Killer is my distaste for manual labor."
-- Dilbert Calendar, January 4, 2004
|
Post #137,820
1/26/04 12:05:47 PM
|
Re: Do you know what VxWorks is used for Ross?
Yes, I can read - I looked over the product at some length incl RTFM. (Never could figure out the basis for the arch tho).
Like I said, this isn't a cellphone. It's not an "embedded device", it's a fucking $500M spacecraft a long way from home.
-drl
|
Post #137,821
1/26/04 12:16:53 PM
|
Is too an embedded device.
None more embeddeder, I'd say.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home Page - Now with added Zing!]
|
Post #137,822
1/26/04 12:19:13 PM
|
Same Difference...
Works on many levels. VxWorks was a far better choice than Linux at the time it was designed, VxWorks was far better than Windows Embedded at the time.
VxWorks has a shining point, it runs in low-current environments, it operates electronic switches and can use many different type of elements (PLC, sensors, processing centers, cameras), if the element has a documented way to be interacted with... (most proprietary tools do) VxWorks can almost always operate it properly.
VxWorks does stand well. VxWorks runs on ARM, MIPS and a few others.
This rover is just one big embedded device with lotsa (simpler)embedded devices embedded in it as well.
I don't think the choice of Operation Environment really means anything. If they would have chosen Linux... or even OS/2 these kinds of thing DO happen.
And about NASA Coding, there is a whole department that has managed to get a ratio of Bugs per Lines of code ... so close to zero is isn't even funny. The Shuttle Operational Code is probably the most error free code in the world.
--
[link|mailto:greg@gregfolkert.net|greg],
[link|http://www.iwethey.org/ed_curry|REMEMBER ED CURRY!] @ iwethey
"Lately, The only thing keeping me from being a
Serial Killer is my distaste for manual labor."
-- Dilbert Calendar, January 4, 2004
|
Post #137,827
1/26/04 12:38:35 PM
|
Point missed
I would not have used ANY canned software of ANY kind, but instead would have applied the principles of RTOS design to build a totally customized solution for THIS ONE spacecraft - this has worked pefectly in the past for far more complex devices. The Viking landers had rocket motors and actually *landed* on Mars - as mentioned the Apollo computers and software were all sui generis and a miracle of tight engineering.
I'm sure VxWorks makes a superior cellphone OS. Or DVD player. Or a robotic vacuum. But adding layers of proprietary unknowns to something that HAS to work EXACTLY as spec'ed is asking for trouble, and lo, trouble didth show his Face. Need we mention the fact that the previous mission's computer turned off the descent motors 100 ft off the ground? *splat*
-drl
|
Post #137,828
1/26/04 12:46:22 PM
|
You don't need to mention it,
because it's got feck all to do with the subject at hand; that was a metric/imperial measurements SNAFU. Nothing to do with an OS; the software worked perfectly given the input.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home Page - Now with added Zing!]
|
Post #137,948
1/26/04 5:23:44 PM
|
That's called HUBRIS
Screw hundreds of programmers over dosen years. I will use the principles of RTOS an magically produce a better system in a year, at the cost of, well, only a few hundred million dollars.
And then the better system will not go anywhere, because the money needed for launch were spent on software.
--
Select [link|http://www.glumbert.com/pictures/Default.asp?index=30|here].
|
Post #137,960
1/26/04 5:38:47 PM
|
Re: That's called HUBRIS
No, it's called targeted programming for minimal chance of failure. If one guy can write his own RTOS to control a telescope and create an entire idiom in so doing, it should not be hard to repeat his effort.
-drl
|
Post #137,965
1/26/04 5:45:34 PM
|
A telescope, a microscope, an antenna, a power system,
a robotic arm, a digital camera, a propulsion system, a rudimentary AI, a lot of things I left out.
--
Select [link|http://www.glumbert.com/pictures/Default.asp?index=30|here].
|
Post #137,975
1/26/04 5:50:56 PM
|
And?
Every one needs its own targeted control module. The underlying structure should be built exactly for the purpose of controlling those things. There should not be one single wasted line of code, or one bit of wasted memory.
Now, are you telling me that the VxWorks based solution is that tight?
Also - look at the results. Apollo - perfect. Shuttle computers - perfect. Vikings - perfect. Mariners to Mercury, Venus, and Mars - perfect. Voyagers and Pioneers to the outer planets - perfect. Only in recent years are things getting fucked up by bad software. What more proof do you need, a core dump from Spirit? This entire problem with the rover was caused by shitty software and/or shitty software related maintenance.
-drl
|
Post #137,981
1/26/04 5:54:03 PM
|
And you know this how?
Yeah, I'm sure that NASA hired some REAL dumb programmers for this job.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home Page - Now with added Zing!]
|
Post #137,987
1/26/04 6:01:55 PM
|
It's POCS
plain old common sense.
What is the former failure rate of NASA spacecraft computing?
Somewhere around 0.
What is the failure rate of business computing based of "tested methologies using canned software"? What, 50-60 percent?
You decide.
How many really shitty engineers have I met?
Somewhere around 0.
How many shitty IT types have I met? I mean - no vision, sloppy, slapdash, careless, clueless? No telling - dot lots and lots.
You decide.
NASA's webpage talks abot ISO.Bullshit and TQManglement. It's their "corporate ethos". Before, someone like John Houboult could go straight to the top with an issue if he felt justified. Now, 10 layers of total quality management would be in his way.
You decide.
-drl
|
Post #137,988
1/26/04 6:03:14 PM
|
Way to not answer the question.
How do you know?
Answer: you don't.
Space is a HARD PLACE TO DO BUSINESS. STUFF BREAKS. GET OVER IT.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home Page - Now with added Zing!]
|
Post #138,013
1/26/04 6:18:55 PM
|
Re: Way to not answer the question.
Peter, in my other life before bumness descended on me like a broken rover, I was a "software engineer" in the Radar and Instrumentation Lab at Ga. Tech Research Institute. We dealt with hardware all the time (Star Wars). No one had VxWorks or any of that BS. We ran hardware simulations on large 'frames, and then coded directly to the simulator. My part was radar codes. Everything was home grown. It always worked. I wonder why?
-drl
|
Post #138,014
1/26/04 6:20:27 PM
|
Because it was a simulator :-)
Simulators have a tendency to be like the environment you're coding to.
Wonder why we have bugs on the road but not in the lab? Wonder no more. We can't put a motorway in our lab.
Peter
[link|http://www.debian.org|Shill For Hire]
[link|http://www.kuro5hin.org|There is no K5 Cabal]
[link|http://guildenstern.dyndns.org|Home Page - Now with added Zing!]
|
Post #138,020
1/26/04 6:26:29 PM
|
Re: Because it was a simulator :-)
This was the standard way of dealing with hardware of any complexity. The Apollo computers were done that way. Intel makes CPUs like that. The hardware has design specs, you feed them in, and run them.
One thing we did was model something like a tank, bounce fake radar from a fake antenna off the fake tank, then calculate the cross section of the return - then go out and deal with an actual radar. The numbers always matched.
-drl
|
Post #138,021
1/26/04 6:27:00 PM
|
BTW, Pathfinder used VxWorks too ...
... with interesting results:
[link|http://catless.ncl.ac.uk/Risks/19.49.html#subj1|http://catless.ncl.a.../19.49.html#subj1]
--
Chris Altmann
|
Post #138,027
1/26/04 6:45:18 PM
|
heh,
with hardware, it's always timing :)
Could one reason the "homegrow" solutions have been so good - sometimes things were honed down to the "literally counting clock cycles" level.
-drl
|
Post #137,787
1/26/04 10:29:43 AM
|
I thought WinCE was really stable?!?
If you push something hard enough, it will fall over. Fudd's First Law of Opposition
It goes in, it must come out.Teslacle's Deviant to Fudd's Law
[link|mailto:bepatient@aol.com|BePatient]
|
Post #137,799
1/26/04 11:00:00 AM
|
As long as you don't run more than 32 threads...
|
Post #137,832
1/26/04 1:00:21 PM
|
Total... not per app.
|
