Do you know what VxWorks is used for Ross?

Post #137,806 by folkert 1/26/04 11:23:22 AM Reply	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!] @ *i_wethey* "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 by deSitter 1/26/04 12:05:47 PM Reply	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 by pwhysall 1/26/04 12:16:53 PM Reply	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 by folkert 1/26/04 12:19:13 PM Reply	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!] @ *i_wethey* "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 by deSitter 1/26/04 12:38:35 PM Reply	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 by pwhysall 1/26/04 12:46:22 PM Reply	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 by Arkadiy 1/26/04 5:23:44 PM Reply	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 by deSitter 1/26/04 5:38:47 PM Reply	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 by Arkadiy 1/26/04 5:45:34 PM Reply	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 by deSitter 1/26/04 5:50:56 PM Reply	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 by pwhysall 1/26/04 5:54:03 PM Reply	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 by deSitter 1/26/04 6:01:55 PM Reply	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 by pwhysall 1/26/04 6:03:14 PM Reply	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 by deSitter 1/26/04 6:18:55 PM Reply	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 by pwhysall 1/26/04 6:20:27 PM Reply	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 by deSitter 1/26/04 6:26:29 PM Reply	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 by altmann 1/26/04 6:27:00 PM Reply	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 by deSitter 1/26/04 6:45:18 PM Reply	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

Welcome to IWETHEY!